什么是服务治理平台？

上次被问到什么是服务治理平台？谈谈你对服务治理平台的理解？

我觉得谈服务治理，首先要知道什么是微服务？

微服务就是一些协同工作的小而自治的服务，两个特性简单连接，分散管理。

Ø简单连接

1、在连接通道方面，微服务很轻，一般采用轻量级的通讯协议（如HTTP）和简单数据格式（如JSON）。

2、无需中心节点提供复杂业务处理，把业务的职责还给服务端，更灵活地响应业务变化。

Ø分散管理

1、分散业务-业务高内聚、低耦合，简化依赖关系

2、分散数据-微服务数据块内部的表紧密相关，块间数据相关性弱。在实施层面，数据逻辑上分离，或者使用独立数据库，物理上隔离。

3、分散物理资源-借助虚拟机和容器技术，非常适合微服务部署，对服务器资源更高效地利用。

我们既然谈微服务，那么先看看什么不属于微服务呢？我们从架构演进说起。从最初的MVC架构到RPC架构，再到SOA架构，最后到了我们的微服务架构。

再谈为什么要微服务？

在传统的应用架构及开发模式下，产生了一些问题，总结如下:

l 系统复杂

l 环境设置复杂

l 不兼容技术无法混合使用

l 多应用间无法有效隔离

l 开发、测试、线上版本管理复杂

l 运维困难

l 无法拆分

l 难以扩容缩容

l 编译时间长

而微服务架构正是在这种环境下应用而生。微服务主要是为了应对复杂度；相对于单一的复杂系统，该架构由多个简单的服务组成，这些服务之间存在复杂的交互，其目标在于确保复杂度能够得到控制。相比基于ESB的SOA架构，微服务架构具有如下优势：

	优势	劣势
单体	•人所众知：传统工具、应用和脚本都是这种结构 •IDE友好：Eclipse、IntelliJ等开发工具多 •便于共享：单个归档文件包含所有功能，便于共享 •易于测试：单体应用部署后，服务或特性即可展现，没有额外的依赖，测试可以立刻开始 •容易部署：只需将单个归档文件复制到单个目录下	•不够灵活：任何细修改需要将整个应用重新构建/部署，这降低了团队的灵活性和功能交付频率 •妨碍持续交付：单体应用比较大时，构建时间比较长，不利于频繁部署，阻碍持续交付。 •受技术栈限制：必须使用同一语言/工具、存储及消息，无法根据具体的场景做出其它选择 •技术债务：“不坏不修（Not broken，don’t fix）”， 系统设计/代码难以修改，偶合性高。
SOA	•服务重用性：通过编排你基本服务以用于不同的场景 •易维护性：单个服务的规模变小，维护相对容易 •高可靠性：使用消息机制及异步机制，提高了可靠性 •高扩展和可用性：分布式系统的特性 •软件质量提升：单个服务的复杂度降低 •平台无关：可以集成不同的系统 •提升效率：服务重用、降低复杂性，提升了开发效率	•过分使用ESB：使得系统集成过于复杂 •使用基于SOAP协议的WS：使得通信的额外开销很大 •使用形式化的方式管理：增加了服务管理的复杂度 •需要使用可靠的ESB：初始投资比较高
微服务	•简单：单个服务简单，只关注于一个业务功能。 •团队独立性：每个微服务可以由不同的团队独立开发。 •松耦合：微服务是松散耦合的。 •平台无关性：微服务可以用不同的语言/工具开发。 •通信协议轻量级：使用REST或者RPC进行服务间通信	•运维成本过高 •分布式系统的复杂性 •异步，消息与并行方式使得系统的开发门槛增加 •分布式系统的复杂性也会让系统的测试变得复杂

基于微服务帮助我们解决的实际问题及架构上的优势，我们选择了微服务架构，那么微服务架构后又会带来什么问题？这些问题该如何解决呢？

微服务不仅仅是带来服务拆分、编排管理、持续集成、部署等一系列问题，微服务内部也会有很多问题，诸如：

针对企业使用微服务架构后带来的一系列，也就有了服务治理平台。