子曾经曰过:工欲善其事,必先利其器。要做微服务架构的转型,不是“干就完了”,而应该“谋定而后动”。之前我们谈到过,微服务化的转型是一个量变引起质变的过程,这就意味着微服务转型不是逐个拆分和替换就能解决的, 微服务化转型的难点在于统一管理控制。
那么,对应前两篇文章中提到的微服务转型的烦恼和误区,怎样通过统一管理解决微服务化难点,我们认为要做到以下四点:
这“四个统一”基本上已经覆盖了微服务化建设的所有工作。那么这四个统一应该从哪里入手呢?
应用服务的管理依赖于服务发现,微服务间访问控制依赖于通信架构,服务发现和通信架构基本上被微服务框架所决定。 因此微服务建设的第一步就从微服务框架入手,制定统一的微服务架构和通信规范,用于新系统的建设,对于老系统就一边逐步改造,一边兼容现状。
接下来进入本文的重点,统一技术架构规范需要从以下方面开始建设:
01
微服务
统一微服务框架规范
首先,微服务多数是需要依赖于微服务框架的,说“多数”是因为在微服务的理念下,只要是分布式的、独立运行又互相依赖的应用服务,都可以叫做微服务。这里微服务框架提供了一些功能的便利,如服务发现、服务间通信、负载均衡策略等通信治理的功能。 因此,微服务框架的选择会影响到注册中心和通信协议的选型。
这里有必要罗列一下目前使用较多的两种框架 SpringCloud 和 Dubbo: SpringCloud上手比较简单,通信采用 http 协议,配套组件很丰富,而且社区比较活跃,比较适合数字化转型中的企业使用;如果选用 Dubbo 框架,则服务间通信协议为一种基于 RPC的 Dubbo 协议,配套的组件较匮乏,社区曾停更过一段时间,但是使用习惯的人在编程时很舒服,服务间调用跟工程内调用没有差别,比较适合 Dubbo 老手使用。另外,使用 SpringCloud 框架,在做能力开放场景中,http 的协议更容易发布在 OpenAPI上,Dubbo 则不得不增加协议转换。
总之,需要先确定好企业级微服务框架及版本,并推行企业内部适配和使用,以此规范通信协议。
02
微服务
统一注册中心建设
微服务间通信依赖于注册中心的服务发现,微服务通过注册中心寻址,才能实现服务间互访。在微服务化建设过程中,统一注册中心的建设会遇到很多复杂的情况,如跨网络、跨业务域等问题会增加建设的难度。
注册中心的健康检测功能需要与应用服务做通信连接,因此注册中心的搭建需要考虑企业内部的网络现状。通常的解决方案是每个网络区域建设一套注册中心,当然如果考虑其他的因素,也可以将注册中心之间打通。
那么在同一个网络区域内,如果需要业务域的隔离,就不适合再部署多套注册中心去解决了,那样会增加管理和建设难度,并且极大的增加资源的消耗。解决方法跟具体使用的注册中心有关,我们以 SpringCloud 框架为例,注册中心可以选择 Eureka、Nacos、Consul,分别看一下对应的解决办法:
Consul 中可以划分数据中心,通过 token 划分权限,以此区分不同的业务域,但是 Consul 注册中心在中国已经渐渐要走下舞台的趋势;
Nacos 中有叫做 namespace 的概念,将注册的服务划分开,但是 namespace 的功能需要使用 mysql 存储;
Eureka 却没有类似隔离,或者划分区域的功能,但是我们依然可以通过访问控制,通过白名单的方式阻止业务域间服务的互访功能。
注册中心的建设就暂且记录这些。
03
微服务
统一配置中心建设
微服务的使用一直离不开配置中心,建设统一配置中心与建设注册中心较为类似。在组件选型上也较为简单和统一,多数都使用携程 Apollo,功能比较强大,可以适合各种场景。当然也有使用 SpringCloud 全家桶中的 config 组件的,但是作为全企业统一的配置中心,组件还是使用 Apollo 较好。
作为统一配置管理的功能组件,Apollo 还是比较好用的,但是作为企业级微服务建设的一部分,服务配置的使用场景就有点不恰当。从使用方法上来说,在 Apollo 中创建一个 APPID,也就是一个配置单元,至于这个配置单元是作用于一个微服务,还是作用于一个业务域,在 Apollo 中没有概念。
因此,我们基于携程 Apollo 组件作为配置的基础原件,真正的业务功能是需要在应用服务管理平台中实现的。
04
微服务
统一观测平台建设
观测应该至少包括监控、链路、日志,那这里的统一观测是指的统一监控平台吗?其实不算是。微服务建设中观测平台是必须建设的一部分,其主要关注点在于服务间通信中的性能监控、服务间调用拓扑、业务调用链追踪,以及业务调用中的业务日志,当然还有性能的告警。这些在微服务运行观测中必不可少,但与统一监控平台还有些差距。
现在有很多 APM 厂商可以提供微服务的相关监控,包括资源、性能、浏览器、线程、app,当然也有拓扑图、链路图等等。其实刚刚介绍的这每一个建设模块,如果做到极致都可以单独作为一个项目建设,比如之前我们基于 gRPC 自研的微服务框架,比如在某银行做的微服务配置管理中心等等。
APM 更是很多企业单独立项的,但是在这里可能不太适合。因为我们的主要目的是微服务的运行观测,那么微服务运行状态数据来源是注册中心,运行性能数据来自 APM,运维策略基于配置下发,依赖于配置中心做运维反馈。那么这三方面的数据在注册中心注册的是服务名,在 APM 中是手动输入的业务名,在配置中心是 APPID,只要三个名字对不齐,就会对使用造成一定的难度,然后就会被废弃不用。
因此,观测平台的建设目标就是一定要“观”起来,所以需要与统一应用服务管理共同建设。
最后总结下,微服务框架、注册中心、配置中心、运行观测都是微服务的工具组件,这四个组件的搭建奠定了微服务改造的技术规范和运行治理规范,因此这是微服务建设的第一步。基于这几个工具组件建设的统一应用服务管理,将是微服务化项目建设的主要内容,我们将在下一篇文章中做详细介绍。
点击BoCloud博云了解更多解决方案
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论