不知道你有没有这样的感受，新系统在前期调研架构的时候，大家都希望优先选择微服务架构，好像一个系统不是微服务架构就OUT了一样。
但是真正的架构设计，并不是哪个架构流行就选哪个，那是要遵循简单、合适、扩展的原则。
所以在选择微服务架构之前，我们应该仔细衡量它的利与弊，分析微服务架构究竟能为系统带来什么优势，同时又会新增哪些挑战。
利
强模块化边界
模块化一直是软件设计中的一个重要原则，有了模块化，我们才可以做到高内聚、低耦合。
实现模块化的方式很多，可以是一个类，也可以是一个独立的组件。
微服务架构则将模块化上升到一个更高的层次，以服务的形式的实现。
服务与服务之间采用远程调用的方式进行交互，这样它们之间没有干扰和冲突，边界非常清晰。
可独立部署
由于服务之间是互相独立的，因此一个服务的变更并需不要其它服务配合，变更完成之后就可以单独测试、发布。
例如我们需要给用户信息加字段，只需要修改用户服务，其它的服务并无感知。而单体架构就要麻烦很多，即使是变更一个小功能点，也需要发布整个系统。
基于这个特性，微服务架构功能迭代的速度币单体架构更快、更灵活。
技术多样性
由于微服务不是集中式管理，所以不同服务的技术团队，可以基于自身技术特点或者服务的业务特性选择完全不同的技术栈。
比如有的团队更熟悉Java，那么他们可以选择Java做为开发语言，另一个团队更熟悉Python，则可以用Python来开发。
再比如数据存储量大的服务使用HBase存储数据，而数据量小的服务使用MySQL。
丰富的技术多样性给了技术团队更多的选择，可以将当前服务的功能发挥到最大化。
弊
研发复杂性
微服务的特点是服务众多，并且实现技术多样，这样带来的挑战就是增加了研发人员的理解和学习成本。
一个单体架构系统，技术栈是统一的，而且系统架构简单，就只有单体应用的几个节点，研发人员理解起来非常容易。
但是一个微服务架构的系统，服务模块可能有几十个，模块之间又存在错综复杂的调用关系，能弄清楚服务之间的关系已经很不容易了，如果是一个人维护多个不同技术栈的服务，那么技术学习的成本也很高。
最终一致性
微服务架构是一种分布式系统架构，对于任何分布式系统而言，数据的最终一致性都是一个绕不过去的坎。
要么在最终一致性上做妥协，由强一致性变为弱一致性。要么使用复杂的设计实现最终一致性，但是开发的成本也会因此提升。
运维复杂性
微服务对于运维在部署、监控、扩展、管理等方面都提出了更高的挑战。
例如服务增多以后，不可能还是手工一个个部署，必须要借助自动化工具批量操作。
追查问题的难度也变高了，一个问题可能涉及多个服务的层层调用，如果没有一个好的链路追踪以及日志查看工具，即使是简单的问题，追查起来也会非常耗时耗力。
总结
最后用一张表格来总结微服务的利与弊。
强模块化边界
研发复杂性
可独立部署
最终一致性
技术多样性
运维复杂性
博文地址
https://www.taowong.com/blog/2018/07/20/microservice-02.html
