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

看来面试用上了吧

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

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

概念

微服务(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. 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。

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

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

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

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

总体来说，在适合微服务的场景下，还是推荐使用微服务架构，在交付过程中，优势还是要大于劣势的

参考文档：从0开始学架构