微服务优缺点解析

前言

首先，微服务不是一个名字，而是一个架构的概念，就像Restful不仅仅是描述api的格式，而更多的是描述基于Restful API的架构是一样的。微服务架构（MSA）是对原来的大型系统而言的，通过横向或者纵向、业务或者架构切分，将一个大型的系统分散成很多微型小系统。当系统复杂到一定程度时，几十号人共同维护一个系统的效率很低，而且出问题的风险也很高。

这时候就需要对系统进行切分，很早之前提出的SOA系统，和微服务的架构理念不谋而合。大家现在使用的基于RPC框架（dubbo、thrift等）的架构也可以视为一种微服务。微服务到现在为止还没有确切的边界和定义，貌似计算机上很多概念都定义不出来边界。但是，我理解微服务之间的通信是http通信，传统rpc调用方式并不是严格的微服务，因为他不能自理，需要依赖，比如可能必须某个rpc服务Producer存在的情况下，rpc服务的Consumer才能启动起来。所以，下文中的讨论，我都以微服务之间以http通信为前提。

微服务有什么好处

解耦：对于我们底层程序员而言，看得见的好处就是解耦。我要实现一个功能，可能并不需要很深入的了解别人的代码，因为程序员嘛，可能都觉得别人的代码是个渣渣（［哭笑不得］）。我可以新作一个微服务，这个服务为其他功能提供服务，又不依赖于原来已有的功能，至于业务逻辑，可以一边上手一边熟悉 内聚，可以独立部署：意思就是我维护的这个微服务，可以独立部署，对其他服务不会是强依赖，不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题。

分布式：微服务架构下不存在一个特别大的系统包含很多中心功能，这样也能提高容错性，一个服务的瘫痪并不会让整个系统瘫痪 权限验证：微服务是高度内聚的服务，我自己的这个服务，我可以定制任意合理规则，而这个规则又只适用于我自己的服务。相比于dubbo RPC调用，http微服务调用的权限验证可以更直接更严格更定制化，而rpc调用时的权限验证，我个人始终觉得不能做的很优雅 数据分开治理，自带分库属性：原来的大系统使用一个数据库，当数据很多流量很大时，就会涉及到分库分表。

而微服务下，每个服务是否使用数据库，数据库是和其他服务公用还是自建，都有很大灵活性，即我觉得微服务自带分库分表属性 系统不会被长期限制在某个技术栈上，在微服务的架构下，整个系统不会受限于java或者nodejs 或者go，而是大家协同不冲突，全部http协议，json格式 各个模块的单元测试容易自动化 等

微服务面临的挑战

通信，http请求速度慢，通常一个操作可能会涉及到多个微服务的相互调用，如果为了完成一个操作而多次从服务端调用不同的微服务，http请求的耗时可能会成为瓶颈，如图1所示。

客户端与服务端的通信需要一个 API GateWay：通常情况下，客户端和微服务们不在一起，而各个微服务会集中部署在一个机房，那微服务之间的互相调用是很快速的，但是客户端和微服务之间的调用会是耗时的。而且，用户的一个动作不能在客户端进行多次连续调用，这样一来速度慢，二来会有泄漏系统架构的风险。正常情况下，在客户端和微服务架构之间会有一个API GateWay。

如图1变成图2所示，GateWay最重要的作用是为客户端提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，为了解决API Gateway单点故障点或者性能瓶颈，通常Gateway也是一个集群，而且客户端的访问控制、账号管理、登录管理等切面通常会在这里处理

微服务很多时，整个链路可能很长，调用失败的风险高，而且e2e自动化测试会成为一个问题 服务注册和服务发现，我司有自己的服务管理系统。我推荐etcd。Google开源的Kubernetes（k8s）貌似也是使用的这个。 分布式事务，这个是微服务系统的大难点，可能需要根据自己系统的情况和业务需求进行定制了，我推荐补偿性分布式事务和基于消息的分布式事务。（下次有时间介绍一下常用的集中分布式事务要怎么做）

基于微服务架构和架构实施过程中存在的优点和缺点：

采用微服务架构的优点

采用微服务架构可以更好的实现DevOps开发运维一体化，同时因为微服务架构下各个微服务模块相对独立和松耦合，因此在后续业务变更的分析和处理中往往能够更加敏捷快速的响应，同时相对影响也最小。

整个业务系统水平扩展更加容易，单体应用要扩展往往数据库是大问题，而在微服务架构下实现了单体应用的垂直拆分，可以更加容易的通过廉价的X86服务器资源来实现水平扩展。

通过微服务架构可以更好的提升各个模块的可复用性和可组装性。通过微服务架构更好的实现了原单体应用内部各个组件或模块的彻底解耦，通过解耦本身也降低了原单体应用内部的复杂度。

可以使研发过程根据敏捷和小团队化，包括和敏捷软件开发最佳实践更好的匹配，每个微服务模块都可以形成独立的敏捷小团队进行开发和部署上线。

进一步在传统单体应用内部实施SOA参考架构思想，体现业务能力组件化，组件能力服务化，同时也可以更好贯彻各个能力中心和前端应用组件的分离，实现共性能力下沉和复用。

采用微服务架构的缺点或困难

微服务架构需要开发团队本身具备较强的团队管理能力，软件研发技能，因为管控的粒度单位已经从原有业务系统变化为了微服务模块。

微服务架构本身会提升开发难度和工作量，特别是上层的跨多个微服务模块或组件的功能应用的实现，往往需要在前端进行服务组合而不是传统方式在数据库层做SQL关联。

由于各个微服务模块完全相对独立和松耦合，因此对于跨多模块业务带来的分布式事务问题是必须解决或找寻替代方案。特别是在微服务架构下数据库已经进行了垂直拆分，对于跨库访问本身的分布式事务一致性问题是最需要和重视的问题。

服务的治理将成为实施微服务架构中重点问题，包括了服务全生命周期管理，服务后期的运维和监控，性能分析，服务链监控等。如果企业本身的IT治理和SOA管控治理能力弱，那么及时开始正常实施了微服务架构，到了后期的运维管控也很难做的很好。其核心原因还是管控的粒度更加细，需要管控的微服务模块，服务接口都会呈现指数级增加。

集成复杂度增加，任何彻底的分解都将带来集成的复杂度，即模块在集成时候需要外部微服务模块更多的配合。

部署复杂度增加，由于微服务模块需要独立部署，往往涉及到多达上100个容器的安装和部署和集成等相关工作，这也是需要和Docker集成并实现自动部署的一个原因。

微服务很多时，整个链路可能很长，调用失败的风险高，而且e2e自动化测试会成为一个问题 服务注册和服务发现，我司有自己的服务管理系统。我推荐etcd。Google开源的Kubernetes（k8s）貌似也是使用的这个。 分布式事务，这个是微服务系统的大难点，可能需要根据自己系统的情况和业务需求进行定制了，我推荐补偿性分布式事务和基于消息的分布式事务。（下次有时间介绍一下常用的集中分布式事务要怎么做）