网关和php框架技巧_技能干货做事网格与微做事开拓框架融合实践

- 对 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 如何向做事网格平滑过渡。

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 可独立支配，不会绑定支配系统，无论虚机还是容器还是 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 在这方面供应了一个完全的方案，可以供企业转型时利用。

end：如果你以为本文对你有帮助的话，记得关注点赞转发，你的支持便是我更新动力。