标签：过多 dir == 属性 结构 异步 修改 cti 新技术
概念微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个微服务代表着一个小的业务能力。
微服务是根据具体业务领域边界划分出来的能独立运行的程序，并且可以独立部署，可以根据业务量横向扩展，修改不会影响其他程序正常运行。简单一句话：微服务是有一定边界的有自己上下文的服务架构理念。
微服务虽好，但也并非完美。
微服务从字面意思就可以知道强调服务的“微”，但是这个微的粒度，多数人都理解错误，有人说：微到不能再微是微服务划分的理念。我不这样认为，微服务的领域边界是根据具体业务来划分，过度的划分，只会导致微服务的数量急剧增加，团队的效率急剧下降。有的团队只有5~6个人，然而却拆分出几十个微服务系统，平均每个人要维护5~10个微服务，这样做给团队带来的只有负面效应。无论是开发，测试，还是运维都需要在多个微服务之间不停的切换。
当微服务上线之后，几十个微服务需要启动几十个进程，在加入了负载均衡与消息中间件后，进程的数量还会持续添加。运维与编排全部这些服务是个“令人望而却步的任务”。
当微服务粒度过细，会造成代码复用度进一步降低，一些通用的代码你可能需要在多个服务间进行copy，如果某段代码有问题，你同时需要修改多个服务代码，当然同种语言可以使用代码共享库来解决，但是在多语言的情况下是行不通的。
无论微服务怎么样划分边界，业务上无法避免在多个服务间的事务性操作。最简单的下单场景：很多情况下订单和用户资产是不同的微服务，当用户支付成功，扣除用户资产和更改订单状态（还有减少商品库存）应该是一个原子性操作，如果在以前的单体应用公用一个数据库的情况下，用DB的事务很容易实现原子性操作，但是在微服务环境下，实现事务有一定的难度，尤其是当服务间采用异步操作的时候，这就很复杂了，这要求我们得“管理好相关联的ID以及分布式事务，将各种动作绑定在一起”。
服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。从理论的角度来计算，n 个服务的复杂度是n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度：
服务间的通信都采用标准的Http或者Rpc协议，只要是通过网络的调用，就会耗费资源，就会花费更多的执行时间。如果一个请求需要顺序的调用N层服务，那么这个请求所花费的时间是不容忽视的，这在大并发的系统中是致命的性能损耗存在，系统的吞吐量会大幅下降。虽然增加硬件在一定程度上会缓解这种问题，但是却在根本上解决不了问题，而且在成本上会大幅度上升。
另外，服务的调用链太长，定位系统问题很难。一个业务请求会经过N个微服务，任何一个服务有问题，都有可能会导致业务失败。由于调用的微服务过多，而且异常有扩散的属性，快速定位服务问题对于开发以及测试来说，是一件很复杂并且很难的事情。如下图所示：
如果服务C发生故障，开发定位问题的时候需要从服务A开始追踪，然后追踪服务B，然后是服务C，如果调用链更长的话，还需要继续追踪。当定位到问题之后，可能已经过去了几个小时，这在一些敏感的系统中是不允许的。如果服务的复杂性如下图所示，该怎么办呢？
微服务的架构设计中，做好服务的追踪是很重要的
如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。
当服务的数量到达一定程度，假如如上图所示，服务的治理难度就会被提上日程。当微服务的种类和数量越来越多，如果没有微服务的治理系统去支撑，微服务的优势就会变为劣势，包括每个服务的注册和发现，每个服务的部署，每个服务的隔离，甚至每个服务的路由。
如果还是人工去干预这些，最终服务系统将会变的一片混乱，微服务推重的快速交付，横向扩展等特性也将变的复杂。
微服务的重点不止在边界的划分，还有服务的治理。就像容器一样，容器很重要，但是容器编排同样重要。
参考文档：从0开始学架构
更多精彩文章
标签：过多 dir == 属性 结构 异步 修改 cti 新技术
原文地址：https://blog.51cto.com/zhanlang/2541483
