瞎干，就完了！迈好微服务化的第一步

子曾经曰过：工欲善其事，必先利其器。要作微服务架构的转型，不是“干就完了”，而应该“谋定然后动”。以前咱们谈到过，微服务化的转型是一个量变引发质变的过程，这就意味着微服务转型不是逐个拆分和替换就能解决的，微服务化转型的难点在于统一管理控制。

那么，对应前两篇文章中提到的微服务转型的烦恼和误区，怎样经过统一管理解决微服务化难点，咱们认为要作到如下四点：

1. 统一应用服务管理：将敏态、稳态的全部业务系统、全部不一样框架的应用服务统一管理和展现，这是建设的最基本目标，也是最核心的目标，其余的所有围绕这里展开。

1. 统一权限控制管理：这里的权限控制是指服务间调用的访问权限控制，经过不一样的控制维度，最终达到稳态、敏态、异构框架、异构协议间的访问，作到服务间通讯的自由控制和动态生效。

1. 统一技术架构规范：尽管现状是极其的五花八门，可是咱们的最终目标仍是想要统一技术架构。目前包括银行在内的较多的企业机构，都存在 SOA、独立的单体应用系统、独立的通讯协议和报文，也许还有 SpringCloud 的微服务和 Dubbo 的微服务并存，可是无论有多少种架构和体系，咱们要作的就是先兼容，后统一。那么在统一以前，咱们须要先立规范。

1. 统一设计服务化系统：这里就涉及了容易“谈虎色变”的拆分问题，拆分首先是总体的考虑，功能模块的复用率、业务量、独立性，都是考量的范围。服务化的将来是中台，独立的考虑某一个业务系统，对中台化毫无帮助，因此须要统一的设计和建设，这也是云原生的基本理念。

这“四个统一”基本上已经覆盖了微服务化建设的全部工做。那么这四个统一应该从哪里入手呢？

应用服务的管理依赖于服务发现，微服务间访问控制依赖于通讯架构，服务发现和通讯架构基本上被微服务框架所决定。所以微服务建设的第一步就从微服务框架入手，制定统一的微服务架构和通讯规范，用于新系统的建设，对于老系统就一边逐步改造，一边兼容现状。

接下来进入本文的重点，统一技术架构规范须要从如下方面开始建设：

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博云了解更多解决方案