转载

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

点击上方“蓝字”带你去看小星星

菜菜哥，上次听你讲了微服务和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，如果调用链更长的话，还需要继续追踪。当定位到问题之后，可能已经过去了几个小时，这在一些敏感的系统中是不允许的。如果服务的复杂性如下图所示，该怎么办呢？

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

自动化支撑

如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。
当服务的数量到达一定程度，假如如上图所示，服务的治理难度就会被提上日程。当微服务的种类和数量越来越多，如果没有微服务的治理系统去支撑，微服务的优势就会变为劣势，包括每个服务的注册和发现，每个服务的部署，每个服务的隔离，甚至每个服务的路由。
如果还是人工去干预这些，最终服务系统将会变的一片混乱，微服务推重的快速交付，横向扩展等特性也将变的复杂。

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

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