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

文章插图

大家好，由于当前重心在知识分享视频的创作上面，因此减少了图文类文章的更新，但是对于一些关键点的思考仍然会更新图文，重点不在于长篇大论，而是将我的关键思考点讲清楚，内容不会再体现完整的体系化，而是类似经验点的分享。
什么意思呢？
就是我的文章你拿去转载没什么用，内容会很零星，但是这些思考点你沉下心来结合你自己的工作学习实践来阅读，还是会有帮助。
对于微服务，从基本概念到开发到治理，我在前面都谈过相当多的文章，今天谈这篇文章还是对于腾讯在北极星后又发布和开源了一个云原生标准的一站式微服务管理框架 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）。