微服务开发和治理-如何屏蔽软件架构的复杂性

大家好，由于当前重心在知识分享视频的创作上面，因此减少了图文类文章的更新，但是对于一些关键点的思考仍然会更新图文，重点不在于长篇大论，而是将我的关键思考点讲清楚，内容不会再体现完整的体系化，而是类似经验点的分享。

什么意思呢？

就是我的文章你拿去转载没什么用，内容会很零星，但是这些思考点你沉下心来结合你自己的工作学习实践来阅读，还是会有帮助。

对于微服务，从基本概念到开发到治理，我在前面都谈过相当多的文章，今天谈这篇文章还是对于腾讯在北极星后又发布和开源了一个云原生标准的一站式微服务管理框架 Femas。感兴趣的大家可以去看下这篇文章。

https://www.infoq.cn/article/KksAEfXidiM2iwZMvZ0q

但是看了以后，发现这个平台更多还是应用到公有云，面对多租户的PaaS云原生平台中的微服务管控和治理上面。其本身强调了多种微服务开发框架，类似Dubbo，SpringCloud，gRPC的适配，多种服务注册中心，类似Eureka，Nacos，Consul的纳管和适配，多种微服务和API网关，多种可观测性开源组件的适配。

简单来说就是，不论你原来微服务开发采用的是什么开发框架和环境，微服务治理采用的是什么开源软件，都可以纳入到Femas进行统一的管理。

整个纳入管理的时候，又不需要对已有的微服务框架，微服务程序进行改动。

对于Femas本身也是基于ServiceMesh的思路，通过下放Sidecar边车代理的方式来实现各种适配能力，各种安全，日志，限流熔断，链路监控能力。

我在前面分享过一篇微软Dapr微服务框架的文章，参考：

微软开源Dapr微服务框架-云原生应用和微服务发展主流趋势

从Dapr的分层架构上，可以简单地理解为北向接口和能力开放，内部业务组件和逻辑实现，南向底层能力适配三个方面的内容。对于最上层的API层是最容易理解的，即将内部组件能力发布为API接口服务，既可以是Http Rest API接口，也可以是Rpc接口，而且可以做到灵活发布给前端应用使用。

对于Building Blocks，除了架构图里面谈到的状态管理，资源绑定，发布订阅，可观测性等能力外，更加重点是是和能力绑定在一起的核心业务组件和功能实现。也就是Building Blocks仅仅是核心组件逻辑实现附属的Sidecar能力。核心组件能力如何实现呢？你仍然可以按照传统的编程语言来实现你的核心业务规则和逻辑。

但是这个开源框架更多是站在公有云PaaS平台，面对多租户，多种异构微服务应用场景的时候适用。但是回到一个企业内部的IT应用开发，在微服务架构应用和选型的过程中，绝对不会说出现采用多种服务注册中心，多种网关，多种开发框架的问题。

那么企业级微服务开发者真正要解决的问题在哪里？

这个也是我强调的，对于企业内的微服务开发，应该是屏蔽微服务架构，开发框架，微服务后续治理和可观测性的诸多复杂性，真正让微服务开发尽量的简单和纯粹。

架构师应该做好这种屏蔽，不是说每个开发人员都需要去了解微服务底层框架技术原理，都需要去了解复杂的链路监控，限流熔断的实现。开发人员更多的重心是在功能的实现上，而不是微服务后续的管控治理。

微服务开发和微服务治理一定要分离。在微服务设计和开发过程中不应该引入任何的微服务治理内容。

先摘录一段内容：

基于传统组件面临的种种问题，Red Hat 首席架构师 Bilgin Ibryam 对云原生领域的微服务架构发展提出了 multi-runtime 的理念。runtime 作为理论的出发点，Bilgin Ibryam 提出现代分布式应用程序的需求分为 4 类，分别是生命周期（lifecycle）、网络�.NETworking）、状态（state）和绑定（binding）。

• 生命周期：编程语言会指定生态系统中的可用库、打包格式和运行时，自动化部署、弹性伸缩、自愈等代表了应用程序生命周期的需求。
• 网络：从更广泛的角度去掌握网络，例如 DNS、流量管控。
• 状态：依赖于底层的状态的分布式能力，如缓存、服务编排和工作流、分布式单例、临时调度。
• 绑定：在跟外部系统的集成过程中，依赖于协议转化，错误恢复等能力。

如上面这个图。

简单理解就是我只想做好中间方块内容，实现相关的功能和API接口的开发。其它事情都不应该让开发人员操心。

而其他事情就包括了这个组件本身的生命周期和运行时管理(容器云集成），东西流量管理（服务注册发现），南北流量管控（微服务或API网关），可观测性（状态管理，链路监控），服务治理（安全，限流熔断，日志审计）等。

如果我是开发者我希望达到的一个目标就是方块外围的各种能力都不需要我在开发阶段去关心，都是应该在后续可以通过Sidecar边车代理的模式来灵活配置和实现。

我开发一个微服务，重点是实现业务功能，并且写好我的对外接口函数。

任何一个接口函数本身就应该具备多种接口协议的发布能力。举例来说如果是内部的各个微服务组件之间的调用，应该自动化的发布为TCP+RPC调用模式以提升接口性能。而对外发布才发布为Http Rest API接口以屏蔽防火墙影响等。

而这些开发人员也不需要关心，也需要做到可以灵活配置。

对于我开发自测通过的微服务，如果通过编译构建，打包，部署和最终交付到容器云平台，包括后续在容器云平台如何进行资源和状态的监控，组件资源的灵活动态调度，开发人员也不需要关心，微服务运行的全生命周期管理复杂性也不应该在开发态引入。

只有这样开发人员真正的重心才能够放在业务功能开发，业务逻辑的实现上面，而不是去关注微服务技术平台。

对于一个大企业也是同样的道理。

大企业本身也应该是平台+应用的构建模式，可以有独立的技术架构和平台组来辅助微服务开发框架，技术平台，治理平台的建设。而平台组提供给上层应用开发组的能力应该足够简单，不应该将微服务架构本身的一些复杂性引入到技术开发中。

不是每个开发人员都需要去详细了解微服务架构，开发框架，各种微服务治理技术组件和底层实现方案，更多的开发人员应该是使用微服务开发框架，开发过程应该足够简单，真正将重心放在业务和功能实现上。

这才是一个微服务架构设计的时候应该考虑的关键点。