程序员修神之路--要想作好微服务架构，并不是易事！

菜菜哥，上次听你讲了微服务和SOA，明白了不少道理

看来面试用上了吧

呵呵，可是面试官问我微服务有什么优势和缺点...

看来还得给你详细讲一讲微服务

概念

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下，每一个微服务表明着一个小的业务能力。

微服务是根据具体业务领域边界划分出来的能独立运行的程序，而且能够独立部署，能够根据业务量横向扩展，修改不会影响其余程序正常运行。简单一句话：微服务是有必定边界的有本身上下文的服务架构理念。

有点我就给菜菜哥你讲讲吧，看我讲的如何

好呀，洗耳恭听。

微服务优势

1. 微服务更容易的扩展，它基本上是独立的。应对互联网应用中大并发的系统能够作到自动弹性应对。

2. 每一个微服务能够由不一样的团队，采用不一样的技术栈开发，只要遵循约定的协议便可，每一个微服务的修改不会影响到其余服务的正常运行。

3. 微服务的架构思想摒弃了中心化的架构风格，进一步下降了系统间的耦合度，不管是在开发阶段或部署阶段都是独立的。

4. 微服务因为能够快速开发和交付，因此在新技术的接收能力上要远远高于其余系统，例如：将一个传统的系统修改微服务能够快速上云，能够快速采用k8s部署。

5. 每一个微服务都遵循相同的协议标准，因此再团队之间的沟通上能够减小不少没必要要的麻烦。

微服务的优势大致上能够归纳为以上几点了

说的很好啊，可是微服务也有不少缺点，不知道你知不知道

微服务缺点

微服务虽好，但也并不是完美。

服务数量

微服务从字面意思就能够知道强调服务的“微”，可是这个微的粒度，多数人都理解错误，有人说：微到不能再微是微服务划分的理念。我不这样认为，微服务的领域边界是根据具体业务来划分，过分的划分，只会致使微服务的数量急剧增长，团队的效率急剧降低。有的团队只有5~6我的，然而却拆分出几十个微服务系统，平均每一个人要维护5~10个微服务，这样作给团队带来的只有负面效应。不管是开发，测试，仍是运维都须要在多个微服务之间不停的切换。

当微服务上线以后，几十个微服务须要启动几十个进程，在加入了负载均衡与消息中间件后，进程的数量还会持续添加。运维与编排所有这些服务是个“使人望而却步的任务”。

当微服务粒度过细，会形成代码复用度进一步下降，一些通用的代码你可能须要在多个服务间进行copy，若是某段代码有问题，你同时须要修改多个服务代码，固然同种语言可使用代码共享库来解决，可是在多语言的状况下是行不通的。

事务管理

不管微服务怎么样划分边界，业务上没法避免在多个服务间的事务性操做。最简单的下单场景：不少状况下订单和用户资产是不一样的微服务，当用户支付成功，扣除用户资产和更改订单状态（还有减小商品库存）应该是一个原子性操做，若是在之前的单体应用公用一个数据库的状况下，用DB的事务很容易实现原子性操做，可是在微服务环境下，实现事务有必定的难度，尤为是当服务间采用异步操做的时候，这就很复杂了，这要求咱们得“管理好相关联的ID以及分布式事务，将各类动做绑定在一块儿”。

服务关系

服务划分过细，单个服务的复杂度确实降低了，但整个系统的复杂度却上升了，由于微服务将系统内的复杂度转移为系统间的复杂度了。从理论的角度来计算，n 个服务的复杂度是n×(n-1)/2，总体系统的复杂度是随着微服务数量的增长呈指数级增长的。下图形象了说明了总体复杂度：

调用链太长

服务间的通讯都采用标准的Http或者Rpc协议，只要是经过网络的调用，就会耗费资源，就会花费更多的执行时间。若是一个请求须要顺序的调用N层服务，那么这个请求所花费的时间是不容忽视的，这在大并发的系统中是致命的性能损耗存在，系统的吞吐量会大幅降低。虽然增长硬件在必定程度上会缓解这种问题，可是却在根本上解决不了问题，并且在成本上会大幅度上升。

另外，服务的调用链太长，定位系统问题很难。一个业务请求会通过N个微服务，任何一个服务有问题，都有可能会致使业务失败。因为调用的微服务过多，并且异常有扩散的属性，快速定位服务问题对于开发以及测试来讲，是一件很复杂而且很难的事情。以下图所示：

若是服务C发生故障，开发定位问题的时候须要从服务A开始追踪，而后追踪服务B，而后是服务C，若是调用链更长的话，还须要继续追踪。当定位到问题以后，可能已通过去了几个小时，这在一些敏感的系统中是不容许的。若是服务的复杂性以下图所示，该怎么办呢？

微服务的架构设计中，作好服务的追踪是很重要的

自动化支撑

若是没有相应的自动化系统进行支撑，都是靠人工去操做，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。

1. 没有自动化测试支撑，每次测试时须要测试大量接口。

2. 没有自动化部署支撑，每次部署 6 ~ 7 个服务，几十台机器，运维人员敲 shell 命令逐台部署，手都要敲麻。

3. 没有自动化监控，每次故障定位都须要人工查几十台机器几百个微服务的各类状态和各类日志文件。

当服务的数量到达必定程度，假如如上图所示，服务的治理难度就会被提上日程。当微服务的种类和数量愈来愈多，若是没有微服务的治理系统去支撑，微服务的优点就会变为劣势，包括每一个服务的注册和发现，每一个服务的部署，每一个服务的隔离，甚至每一个服务的路由。

若是仍是人工去干预这些，最终服务系统将会变的一片混乱，微服务推重的快速交付，横向扩展等特性也将变的复杂。

微服务的重点不止在边界的划分，还有服务的治理。就像容器同样，容器很重要，可是容器编排一样重要。

哎呀，微服务原来有这么多缺点，我再考虑要不要学呢？

整体来讲，在适合微服务的场景下，仍是推荐使用微服务架构，在交付过程当中，优点仍是要大于劣势的