建设微服务框架体系需要考虑三个关键点
极客时间编辑部
讲述：丁婵大小：2.50M时长：05:27
根据康威定律，当互联网公司业务和团队发展到一定规模，微服务架构是一种必然的演化趋势。近几年，随着电商业务的快速发展，唯品会逐渐实施了微服务架构。在本文中，唯品会业务架构架构师杨钦民分享了他们对微服务框架体系的建设及实践。
我们先来看一下唯品会微服务基础中台架构的设计思路。围绕微服务，唯品会自主研发了微服务框架以及一系列配套的系统，具体如下：
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 采用自己的开发语言进行开发，独立演进，而每个服务均可以采用合适的开发语言，二者互不影响。
此外，在建设微服务框架体系过程中，针对不同业务体量、不同技术储备的公司，还需要思考以下几个关键点：
是选择开源微服务框架，还是选择自研微服务框架？对于业务体量大、技术储备多的大公司，可以根据公司自身情况，考虑自研发微服务框架体系。而中小型初创公司，由于业务体量不是很大，同时技术储备也比较少，技术人员的技术实力也不够深厚，建议选择各种开源微服务框架，构建自己公司的微服务框架体系。
是否选择自构建 Kubernetes 集群。对于有自建服务器机房且业务体量庞大的公司，选择自建 Kubernetes 集群是再好不过了。而针对中小型初创公司，建议选择云服务商，可以更快构建 Kubernetes 集群。
是否选择 Service Mesh 框架。大公司甚至大集团，业务线非常多，技术体系也比较丰富，一般会有多种开发语言并存，同时大公司的技术实力也非常雄厚，此时建议演进到 Service Mesh 框架。而针对中小型初创公司，需要根据自身客观情况考虑，一般都是只有一种开发语言，所以针对此种情况，建议可以选择 Spring Cloud 框架、Dubbo 框架等。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论