微服务架构的优缺点

目录

• 微服务架构
• 优点
• 缺点
• 反例
• 结论

微服务从几年突然火了起来，经常在各种地方见到，刚好有空，整理了一下我的看法。我在18年开始参加工作，刚出来工作时认为微服务是一种“先进”的设计风格用上了就是好的，然而最近回头看，微服务只是为了解决某一些问题的方案，并不适用于所有系统。选择架构，在我看来更像是买东西：找到需要的东西，并且挑出代价最小的质量最好的。没有过时的架构，只有合适的架构。

微服务架构

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。当系统规模大，或程序需要修改的时候，其部署的成本、技术升级的迁移成本都会变得更为昂贵，有一个很常用的解决问题思路，就是分治法：把一个大问题分成N个小问题去解决。微服务的火热，一方面是微服务所需要的基础设施：注册发现、跟踪治理、负载均衡、传输通信、持续集成部署已经有了很多成熟的解决方案；另一方面是越来越多的业务场景信息化，导致我们的系统越来越庞大。

优点

• 服务自治。每一个服务都是一个独立的小应用，可以根据需要去选择该服务使用的编程语言、数据库等，只需要对外接口采取一致通信协议跟格式。《人月神话》里面有一个很出名的理论，一个人10天能完成的活，加到10个人也不会1天完成。服务的拆分也有助于拆分团队，控制单个团队规模，增加开发效率。
• 容错性。可靠系统完全可能由会出错的服务组成，在微服务的设计中，有自动的机制对其依赖的服务能够进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。
• 高频繁的部署需求，微服务架构支持快速、频繁的部署。由于每个服务都是独立的，可以对其进行独立的部署，而不会影响其他服务。这对于需要快速交付新功能和修复问题的团队来说是非常有价值的。
• 高可伸缩性。 微服务架构允许每个服务独立扩展，这使得系统可以根据负载的需求进行水平扩展。当某个服务的负载增加时，只需增加该服务的实例数量，而不需要整体扩展整个应用程序。

缺点

• 数据一致性。单体服务时，数据一般都存在同一个数据库中，数据库能很好的保证事务。但服务拆分以后，不同服务有自己的数据库，一个用户请求可能需要多个数据库，做跨库事务是一件很头疼的事情。
• 服务间通信有可能会成为瓶颈。单体架构下的应用大部分只需要进程内的通信，在微服务架构下，会产生大量的进程间通信，进程间通信绝大部分是通过网络，网络IO相较于进程内通信效率低了几个量级，哪怕是使用RPC协议降低了单次服务间调用的成本。
• 监控、管理服务变得更困难。 使用微服务架构必然会导致需要管理的应用数量上升，对系统运维来讲，完全通过人工去管理已经很困难，更多的需要一些自动化工具。另外当一个应用被拆分成多个应用，意味着有可能一个业务请求会出现需要多个服务处理，那么怎么跟踪这个请求链路，出现问题时怎么定位
• 如何拆分才是合理的？采用服务来构建程序，获得的收益是软件系统“整体”与“部分”在物理层面的真正隔离，这对构筑可靠的大型软件系统来说无比珍贵，但另一面，其付出的代价也同样无可忽视，微服务架构在复杂性与执行性能方面做出了极大的让步。一套由多个微服务相互调用才能正常运作的分布式系统中，每个节点都互相扮演着服务的生产者与消费者的多重角色，形成了一套复杂的网状调用关系。对原有系统采用哪种划分方式才能让服务间调用更少更简单？这是一个需要考虑的问题

反例

亚马逊 Prime Video 团队做了一个监控服务，一开始采用了分布式服务架构，如下图

为了减少计算成本高昂的视频转换作业，构建了一个微服务，将处理后的视频内容临时上传到 Amazon Simple Storage Service （Amazon S3） 存储桶。然后，缺陷检测器（其中每个缺陷检测器也作为单独的微服务运行）下载图像并使用 AWS Lambda 同时处理它。但是，对 S3 存储桶的大量调用成本很高。

上述案例中，将应用拆分成多个服务，产生了数据共享问题（需要将共享的数据放在S3存储桶）、服务间的网络调用问题，而这些对于功能相对简单的监控应用来讲是没有必要的
案例详细介绍：https://www.cnblogs.com/zmj-pr/p/17391507.html

结论

微服务更适合于业务复杂、规模庞大的系统。 正如单线程能很好完成任务，没必要用多线程。微服务是有额外开销的。本来简单的进程间通信，或者系统两个部件之间的内存调用，变成了 HTTPS、OAuth、JSON 编码 / 解码，而且每次都需要发生这些简短的对话。当你的系统被分解成 50 万个部件，每一次通信都需要做这些事情，并且你要为每一个事务付费时，成本和复杂性就会增加。