唯品会自研微服务框架 OSP,解决拆分、扩容难题

栏目: 后端 · 发布时间: 5年前

内容简介:马尔文·康威 1967 年提出康威定律:“设计系统的架构受制于产生这些设计的组织的沟通结构。”根据康威定律,当互联网公司业务和团队发展到一定规模,微服务架构是一种必然的演化趋势。近几年,随着电商业务的快速发展,唯品会逐渐实施了微服务架构,面对如此大规模的电商业务,如何进行微服务框架体系的建设;面对电商大促,如何快速大规模扩容;面对如此复杂的电商业务,如何更好的拆分微服务,都是要解决的一系列难题。7 月 14 日,唯品会业务架构架构师杨钦民老师将在 ArchSummit 全球架构师峰会分享唯品会微服务基础中台

马尔文·康威 1967 年提出康威定律:“设计系统的架构受制于产生这些设计的组织的沟通结构。”

根据康威定律,当互联网公司业务和团队发展到一定规模,微服务架构是一种必然的演化趋势。近几年,随着电商业务的快速发展,唯品会逐渐实施了微服务架构,面对如此大规模的电商业务,如何进行微服务框架体系的建设;面对电商大促,如何快速大规模扩容;面对如此复杂的电商业务,如何更好的拆分微服务,都是要解决的一系列难题。

7 月 14 日,唯品会业务架构架构师杨钦民老师将在 ArchSummit 全球架构师峰会分享唯品会微服务基础中台和最佳实践的演讲,我们提前邀请杨老师对分享内容进行预热解读,希望对你 / 团队有帮助。

唯品会微服务基础中台架构设计思路

围绕微服务,唯品会自主研发了微服务框架以及一系列配套的系统:

  • OSP(开放服务平台)微服务框架 ,提供高性能、高可扩展的远程调用机制,实现了契约化多语言服务接口,同时提供了强大的服务化治理能力,可以实现负载均衡、路由选择以及自我保护等。
  • Service Center 统一的服务治理中心 ,对基础服务化项目提供的服务进行治理,将所有服务化项目的配置集中在一起,实现一处配置、多处运行的目标。
  • Mercury 全链路跟踪监控平台 ,实现了全链路调用链跟踪、指标统计、监控告警等,通过 Mercury,应用管理人员 / 架构师等可以全方位把握应用整体拓扑结构、定位全网应用瓶颈。应用开发人员可以定位线上服务性能瓶颈、持续优化代码和 SQL 、帮助快速解决线上问题,IT 运维 / 监控人员可以快速故障告警和进行问题定位、把握应用性能和容联评估、提供可追溯的性能数据。
  • Janus 服务网关 ,为业务服务提供统一对外的、高性能的 HTTP 网关,针对外网支持 HTTPS、HTTP2、HTTP、自定义协议等,针对内网可以自动适配到 OSP 协议。
  • Salus 服务安全管理平台 ,面向 OSP 和 RESTful 形式的服务,提供服务安全管理(认证、鉴权、防篡改)的手段。
  • 基础中间件 ,CfgCenter 应用配置中心实现应用配置管理,Saturn 分布式任务调度平台具备高可用以及分片并发处理能力等,Asgard 一站式存储服务平台可以实现统一管理、统一监控存储服务,VMS 消息系统具备组内广播、消息回溯、消息延时、灰度消息等。

唯品会开发微服务框架 OSP,和 Service Mesh 有哪些异同?

唯品会在设计 OSP 微服务框架之初,就已经单独抽出了代理层 Proxy,类似 Service Mesh 的 Sidecar。客户端与微服务框架代理层 Proxy 部署在同一机器的不同进程,各自独立部署,服务治理逻辑从客户端业务逻辑中解耦出来。

和 Service Mesh 相比,OSP 所具备的优势包括:

  • 加强运维管理, 运维人员可以单独针对 Proxy 进行独立升级、维护,极大加强运维管理能力。
  • 框架可以持续演进, Proxy 作为一个独立的代理层,与服务隔离,并且独立部署和运维,每次框架发布新版本时,无需业务研发部门介入,运维就能独立进行升级和部署,因此服务框架可以持续进行演进。
  • 支持多语言, Proxy 采用自己的开发语言进行开发,独立演进,而每个服务均可以采用合适的开发语言,二者互不影响。

唯品会自研微服务框架 OSP,解决拆分、扩容难题

唯品会拆分微服务过程中遇到的难题

在拆分复杂电商业务系统的过程中,遇到的难题包括:

  • 如何按照组织架构划分以及搭建比较清晰的系统架构,如同康威定律所说:组织架构等同于系统架构,一个好的系统架构需要匹配组织架构,同时组织架构在很大程度上会影响系统架构的走向。
  • 如何界定服务边界,将复杂电商业务拆分成不同的服务时,首先面临的是如何可以清晰的界定不同服务的边界,减少服务间的耦合,其次面临的是服务拆分的粒度,粒度过粗可能会造成服务间的耦合,粒度过细可能会拆分出过多的服务。
  • 如何进行服务聚合,服务拆分之后,当面临复杂业务时,需要考虑多个服务的聚合,是由一个团队进行聚合分别提供各方,还是由各业务方分别聚合。

在微服务框架体系建设实践中,选择开源还是自研?

在建设微服务框架体系建设过程中,针对不同业务体量、不同技术储备的公司,我们需要思考以下几个关键点:

  • 是选择开源微服务框架,还是选择自研微服务框架 如果一些大公司业务体量非常大,技术储备非常多,发展到一定的阶段,可以根据公司自身情况,考虑自研发微服务框架体系。而中小型初创公司,由于业务体量不是很大,同时技术储备也比较少,技术人员的技术实力也不够深厚,建议选择各种开源微服务框架,构建自己公司的微服务框架体系。
  • 是否选择自构建 K ubernetes 集群。 同样,对于有自建服务器机房且业务体量庞大的公司,选择自建 Kubernetes 集群是再好不过了。而针对中小型初创公司,建议选择云服务商,可以更快构建 Kubernetes 集群。
  • 是否选择 Service Mesh 框架。 Service Mesh 是近两年的热点,是否选择跟风演进到 Service Mesh 框架,也是一个考量。大公司甚至大集团,业务线非常多,技术体系也比较丰富,一般会有多种开发语言并存,同时大公司的技术实力也非常雄厚,此时建议演进到 Service Mesh 框架,国内已经有多家有实力的大公司在积极自研发 Service Mesh 框架。而针对中小公司、初创公司,需要根据自身客观情况考虑,一般都是只有一种开发语言,所以针对此种情况,建议可以选择 Spring Cloud 框架、Dubbo 框架等。

2019 年 Kubernetes 在应用开发和运维上有非常重要的能力透出,在唯品会有哪些深入应用?

唯品会基于 Kubernetes+Docker 技术框架研发了 Noah 云平台,涵盖应用的开发、交付、运维和运营全生命周期,整个平台包括主机层、容器层、云平台层、镜像管理、CI/CD,支持灰度分批发布、容器 Auto Scaling、集群节点管理、多集群时间监控等。

  • 开发阶段提供 CI 镜像流水线,本地开发 DockerVM,功能测试环境、联调测试环境给开发和 QA 完成镜像的发布;
  • 生产阶段提供容器发布、容器调度、容器服务注册发现、容器网络互通、集群管理等功能完成运维工作;
  • 提供容器的运行时日志、监控、告警等功能做业务监控。

除此之外,杨钦民老师将于 7 月 14 日在深圳大中华喜来登酒店分享半天的微服务架构培训,分享电商平台微服务架构演进实战,帮助听众了解大规模容器云实施实践,以及微服务框架体系建设经验。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Build Your Own Web Site the Right Way Using HTML & CSS

Build Your Own Web Site the Right Way Using HTML & CSS

Ian Lloyd / SitePoint / 2006-05-02 / USD 29.95

Build Your Own Website The Right Way Using HTML & CSS teaches web development from scratch, without assuming any previous knowledge of HTML, CSS or web development techniques. This book introduces you......一起来看看 《Build Your Own Web Site the Right Way Using HTML & CSS》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

SHA 加密
SHA 加密

SHA 加密工具