子曾经曰过：工欲善其事，必先利其器。要做微服务架构的转型，不是“干就完了”，而应该“谋定而后动”。之前我们谈到过，微服务化的转型是一个量变引起质变的过程，这就意味着微服务转型不是逐个拆分和替换就能解决的，微服务化转型的难点在于统一管理控制。
那么，对应前两篇文章中提到的微服务转型的烦恼和误区，怎样通过统一管理解决微服务化难点，我们认为要做到以下四点：
1. 统一应用服务管理：将敏态、稳态的所有业务系统、所有不同框架的应用服务统一管理和展示，这是建设的最基本目标，也是最核心的目标，其他的全部围绕这里展开。
2. 统一权限控制管理：这里的权限控制是指服务间调用的访问权限控制，通过不同的控制维度，最终达到稳态、敏态、异构框架、异构协议间的访问，做到服务间通信的自由控制和动态生效。
3. 统一技术架构规范：尽管现状是极其的五花八门，但是我们的最终目标还是想要统一技术架构。目前包括银行在内的较多的企业机构，都存在 SOA、独立的单体应用系统、独立的通信协议和报文，也许还有 SpringCloud 的微服务和 Dubbo 的微服务并存，但是不管有多少种架构和体系，我们要做的就是先兼容，后统一。那么在统一之前，我们需要先立规范。
4. 统一设计服务化系统：这里就涉及了容易“谈虎色变”的拆分问题，拆分首先是整体的考虑，功能模块的复用率、业务量、独立性，都是考量的范围。服务化的未来是中台，独立的考虑某一个业务系统，对中台化毫无帮助，所以需要统一的设计和建设，这也是云原生的基本理念。
这“四个统一”基本上已经覆盖了微服务化建设的所有工作。那么这四个统一应该从哪里入手呢？
应用服务的管理依赖于服务发现，微服务间访问控制依赖于通信架构，服务发现和通信架构基本上被微服务框架所决定。因此微服务建设的第一步就从微服务框架入手，制定统一的微服务架构和通信规范，用于新系统的建设，对于老系统就一边逐步改造，一边兼容现状。
接下来进入本文的重点，统一技术架构规范需要从以下方面开始建设：
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
微服务
统一配置中心建设