子已经曰过：工欲善其事，必先利其器。要做微服务架构的转型，不是“干就完了”，而应该“谋定而后动”。之前咱们谈到过，微服务化的转型是一个质变引起量变的过程，这就意味着微服务转型不是一一拆分和替换就能解决的，微服务化转型的难点在于对立管理控制。
那么，对应前两篇文章中提到的微服务转型的懊恼和误区，怎么通过对立治理解决微服务化难点，咱们认为要做到以下四点：
- 对立应用服务治理：将敏态、稳态的所有业务零碎、所有不同框架的应用服务对立治理和展现，这是建设的最根本指标，也是最外围的指标，其余的全副围绕这里开展。
- 对立权限管制治理：这里的权限管制是指服务间调用的拜访权限管制，通过不同的管制维度，最终达到稳态、敏态、异构框架、异构协定间的拜访，做到服务间通信的自在管制和动静失效。
- 对立技术架构标准：只管现状是极其的形形色色，然而咱们的最终目标还是想要对立技术架构。目前包含银行在内的较多的企业机构，都存在 SOA、独立的单体利用零碎、独立的通信协议和报文，兴许还有 SpringCloud 的微服务和 Dubbo 的微服务并存，然而不论有多少种架构和体系，咱们要做的就是先兼容，后对立。那么在对立之前，咱们须要先立标准。
- 对立设计服务化零碎：这里就波及了容易“谈虎色变”的拆分问题，拆分首先是整体的思考，功能模块的复用率、业务量、独立性，都是考量的范畴。服务化的将来是中台，独立的思考某一个业务零碎，对中台化毫无帮忙，所以须要对立的设计和建设，这也是云原生的根本理念。
这“四个对立”基本上曾经笼罩了微服务化建设的所有工作。那么这四个对立应该从哪里动手呢？
应用服务的治理依赖于服务发现，微服务间访问控制依赖于通信架构，服务发现和通信架构基本上被微服务框架所决定。因而微服务建设的第一步就从微服务框架动手，制订对立的微服务架构和通信标准，用于新零碎的建设，对于老零碎就一边逐渐革新，一边兼容现状。
接下来进入本文的重点，对立技术架构标准须要从以下方面开始建设：
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 博云理解更多解决方案