服务网格与微服务开发框架融合实践

读者需具有基础：

- 已对微服务有必定实践经验，使用过一种以上的微服务开发框架
- 对 Service Mesh 有必定理解，知道他是什么，运做机制，能够经过我过去的分享来了解[Service Mesh 在华为公有云的实践](https://gitbook.cn/books/5a1e7dca387c5b4ee351790b/index.html)

话题范围：

- 不会讨论灰度发布，限流，熔断，负载均衡等微服务实现技术，这些 ServiceComb 所有都拥有
- ServiceComb 包含微服务开发框架与配套的管理面服务，是一套微服务解决方案，但不解决 DevOps，应用生命周期管理等，这里不作讨论。

背景

2018 年被称为 service mesh 之年，层出不穷的服务网格产品，愈来愈多的厂商参与进来，提供本身的解决方案。

其中的 Istio 甚至成为了服务网格代名词。但目前我看到的是，通过了 2 年的发展，istio 还未被大规模的使用于生产中。

spring cloud，dubbo 等发展了多年的框架依然有着存量用户，不容易切换到服务网格，由于这势必意味着 2 套解决方案共同存在，那么如何平滑过渡到服务网格也是这些框架的用户关心的事。

此次分享我将讲述 Apache ServiceComb 在开发框架和服务网格的融合实践，也会看到 spring cloud 如何向服务网格平滑过渡。

ServiceComb 架构与实现机制

Apache ServiceComb 在今年推出了[服务网格](https://github.com/apache/servicecomb-mesher)，[配置管理](https://github.com/apache/servicecomb-kie)等多个新服务。

咱们在 17 年看到服务网格的兴起后便开始了服务网格的研发，并于年末在华为云上线商用，今年将它开源捐赠给 Apache 基金会，完善了 ServiceComb 的多语言能力。

得益于咱们原本在 ServiceComb 开发中的积累（go，java 语言开发框架），咱们快速的基于本来的 go 微服务开发框架进行了服务网格的开发，以此来实现多语言的接入。

​

这是当前组件的全景图，mesher 做为服务网格方案可将服务接入到分布式系统中，与 go chassis 和 java chassis 等开发出的微服务打通。

Service center

注册发现中心，管理微服务及版本信息等元数据，而且能够管理框架生成出来的 open API 文档。而这也大大增强了团队之间的合做效率，能够根据文档来进行客户端的开发，测试。

Kie

一个通用的配置管理中心，当前是独立的服务，将来咱们将会接入到配置管理中心，让用户能够在统一的中心进行配置管理（熔断，限流等规则），而且可以管理业务的配置。

go chassis 与 java chassis

2 个框架，都实现了一致的功能，以保证用户体验一致，好比熔断，限流。可根据代码自动生成 open API 文档并上传到 service center

​

以 go chassis 实现为例，基本的运做机制以下：

不一样协议请求进入到各协议 Server，Server 将具体的协议请求转换为 Invocation 统一抽象模型，并传入 Handler chain，在这 chassis 已经默认实现了不少的 Handler，好比熔断，限流等，最终再进入 Transport handler，使用具体的协议客户端传输到目标。

生成的监控数据经过 http API 导出，由 Prometheus 收集处理

Archaius 为动态配置框架，可从各类不一样的 source 中读取配置，好比 kie。

Mesher

服务网格方案，Mesher 之因此能创建在 go chassis 之上快速创建起来，得益于 go chassis 的 invocation 概念

​

即 invocation 不感知协议，能够将协议转换为 invocation，而微服务相关的全部治理能力，都以 invocation 做为标准，因此这些功能就能够彻底复用，只须要扩展 Server 实现便可，代理服务将请求转为 invocation 后，后续的代码就能够复用了。当前基于这个框架，mesher 已支持 grpc 与 http 协议，也支持开发者本身定制。

Spring cloud

提供[spring cloud 的扩展组件](https://github.com/huaweicloud/spring-cloud-huawei)，可使其接入到 ServiceComb 管理面中，帮助 spring cloud 用户平滑向多语言，服务网格转型，Java 再也不是开发微服务惟一的选择，可平滑过渡到使用 go 语言或者 nodejs 等，并将一部分开发团队从框架中解放。

.Net

mesher 支持.Net 应用接入到服务网格，能够与其余语言打通，在一套系统下进行治理。

使用 ServiceComb 构建微服务系统

ServiceComb 可独立部署，不会绑定部署系统，不管虚机仍是容器仍是 kubernetes 平台，均可以部署，部署限制很低。

使用统一的微服务解决方案可打通公司内部各个业务服务的能力，不断复用当前能力，以更快的应对需求而且经过业务暴露出的数据作更多的业务整合，以构建更增强大的业务平台。

我以实际的例子来说述用户使用 ServiceComb 的实践经验。

梅斯医学

多年的 PHP 技术积累，不少程序都是 PHP 的，面临微服务化改造很是困难，而基于 java 技术新开发的业务又要快速开发以应对市场变化。那么微服务化是很是重要的，为了能让服务共同协做。

​

java 能够选用 java chassis 进行微服务化。对于存量 PHP 业务，要求稳定，不碰业务代码，零侵入完成微服务化；对于新开发业务，要求高性能，细化到业务的治理和监控。在这个场景中，一个统一的微服务解决方案变得相当重要。

如下是改造后的架构

​

改造后收益：

java chassis 是一种高性能 java 微服务开发框架，性能获得的提高，PHP 做为动态语言难以承载将来业务量的上升，更多的语言选择意味着业务团队能够自由选择适合服务的语言进行实现，并可以在统一的系统中进行治理。对外暴露使用 Edge Service，一种网关开发框架，与业务部署在同一网络，可将业务能力暴露给其余应用。

同济大学

本来的系统是独立的烟囱式单体，业务能力没法复用，若是想应变不断变化的需求就须要将单体进行拆分，微服务化，以快速复用解耦的已存在的业务能力，前台选择 nodejs 进行开发，使用服务网格接入，然后台所有使用 java chassis 开发。

​

同济使用了多种云服务构建了本身的平台服务，其中的 EI 服务，云容器引擎等商用方案不在本次话题内。微服务引擎就是 ServiceComb 的商用方案名称。

为何开发框架依然是必要的

并不是全部服务都适合服务网格。因为服务网格是应用代理服务，用户态与内核态之间的数据复制致使性能有所降低，而降低的程度基本与一次请求调用传输的 payload 大小相关，越大性能降低越明显。而较小的尺寸，性能降低很小。因此对于请求并发量很大，且处理大尺寸请求的接口最好不要应用服务网格，好比图片，大量数据。开发框架依然是这种场景的首选。

即使使用用户态协议栈，避免了内核态用户态切换以及数据拷贝，但这也[并不是是一个完美的方案]，(https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp-stack/)，因此在某些场景下，使用服务网格将会一直面临性能上的下降，并且当前没有好的解决方案。

使用 ServiceComb，若是是新项目能够一开始所有使用服务网格，在遇到性能瓶颈时再考虑使用开发框架进行优化。

总结

ServiceComb 在微服务领域多年的积累使咱们可以快速的应对服务网格的兴起，而且快速构建出开发框架与服务网格融合的解决方案。在用户对性能有要求的状况下可以使用框架来知足，并对其余语言提供了兼容，而使用 spring cloud 的用户也能够接入到 ServiceComb 中使用服务网格或是 go 语言框架。

为什么架构设计如此重要，由于他帮助你解决非功能性的问题，并促进业务的成功，为业务保驾护航。

微服务做为一种架构模式，给了一种架构指导，也是一种最佳实践。
而该模式的引入帮你解决问题的同时却又引入很多问题须要解决，须要一套强大的框架来帮助你完成这个架构转型，让你更加聚焦于业务功能，免去架构设计上的投入，ServiceComb 的微服务解决方案即是为了解决微服务带来的复杂性而生。

微服务化给业务带来的一个很大的价值是将企业内部的业务能力进行解耦后复用，打通数据，以快速应对变化的市场需求。而随着多年的发展，公司内部一般会积累至关多的技术栈，语言，这些系统(即异构系统)间一般是不产生关系的，数据没法打通，将这些业务进行整合，打破烟囱成为了亟待解决的问题，ServiceComb 在这方面提供了一个完整的方案，能够供企业转型时使用。

对于想深刻了解 ServiceComb 的读者，能够阅读咱们的项目介绍参与到社区：

- https://github.com/apache/servicecomb-mesher: 服务网格- https://github.com/apache/servicecomb-kie：配置管理中心- https://github.com/go-chassis/go-chassis： go 微服务框架- https://github.com/apache/servicecomb-java-chassis： java 微服务框架