虽然微服务概念流行已有一段时日，但任何技术都有其优缺点。看到微服务同时扮演正派和反派角色之后，ThoughtFocus 的技术架构师埃宾·约翰（Ebin John）发文建议开发者，如果你是倾向于将微服务作为默认架构的架构师或设计师，最好问自己以下几个问题。
1. 你的应用程序庞大得足以细分成微服务吗？
微服务是一大堆各司其职的小服务，在理想情况下，每个服务本身就是一个完整的应用程序。
由于微服务在人力和计算成本方面需要最少资源，所以它需要的成本较高，哪怕是轻量级微服务。而且，你的代码库在将来会越来越大，代码库本身可能会添加一个新的领域。但你应该永远记住：当你接近阈值时，设计良好的代码库始终可以切换到微服务。
2. 你是否果真需要扩展应用程序的各个组件？
假设一下。产品负责人向你提出了使用人力资源管理系统（HRMS）应用程序的想法，以满足上万人组织的需求。作为技术爱好者的你立马有一个解决方案：微服务架构。
使用微服务架构的主要优点之一是易于扩展单个组件。你可能会找到组件需要单独扩展的大量应用程序，但你的应用程序果真需要这么做吗？
3. 你的事务跨诸多服务吗？
现在，这可能是最难做出的战略性选择之一。跨多个服务的事务是整个架构的负担。解决跨服务的事务意味着：服务之间的互锁会导致一系列难以追踪的僵局，以及会危及服务健康状况、有时甚至是工程师健康状况的竞态条件。
按照定义，REST 服务是无状态的。它们不应该参与边界不仅限于一项服务的事务。在高性能环境下，两阶段提交 2PC 是不必要的麻烦。而 SAGA 模式只会增加你没有准备好的另一层复杂性。
由于微服务坚持采用分散式数据管理，它带来了最终一致性问题。如果是整体式应用程序，你可以在单个事务中一起更新一堆东西。而微服务需要多个资源才能更新，且分布式事务不受欢迎（这有充分的理由）。因此，开发人员需要意识到一致性问题。
4. 服务之间是否需要经常联系？
在传统的整体式服务上，每个微服务实例由系统内的模块加以表示。模块之间的联系在内存中进行，延迟接近零。微服务的引入意味着，联系由内存中事务完全变成了通过网络传达指令。
有众多久经实践考验的解决方案，但是它们都有代价：延迟。从内存中事务改为基于网络的联系会将延迟从纳秒变为微秒。想象一下，三个不同的服务通过网络彼此联系。假设每个服务调用要花费 100 微秒（这在负载情况下并不少见），那么到头来单单在网络上就要花掉 300 微秒。
而一些应用程序本质上与组件和服务紧密集成。添加的通信层可能会给处理实时数据的应用程序造成灾难性的后果。
除了上述四个问题，在使用微服务之前还需要考虑它的另一些缺点，比如：
1. 复杂性
虽然微服务原本旨在通过将应用程序分解成小组件来降低复杂性，但架构本身的部署和维护却很复杂。
2. 分布成本
微服务是具有模块性的分布式系统，但是同样的分布确实要付出代价。你的整体式服务会部署在大型虚拟机或首选容器上。但如果是微服务，除了多个虚拟机或容器外，服务需要独立部署在理想的环境上。当然服务可能很小，但你可以计算一下总成本。
3. 改编 DevOps
这可能有益也可能有害，如果你是小型企业的成员，成立一支 DevOps 团队会弊大于利。不过有一点倒可以肯定，要是没有专门的 DevOps 团队，你就无法维护和监控微服务。
4. 集成紧密
一些应用程序天生就紧密耦合。将它们分开来以“适应”架构将会带来灾难。
5. 缺乏经验
这对任何新技术的采用来说都是重要的考虑因素。但是说到微服务，由于拥有抽象定义，造成的危害尤其大。
6. 混乱的数据合约
在团队内部设定数据合约与团队之间共享数据合约大不相同。你在接触微服务时，你的团队可能不在同一个地区，更不要说团队成员都采用同一种编程语言了。为特定要求制定数据合约会耗费你的时间和空间。
7. 调试
每个服务都会有自己的一组日志文件要审查，更多服务意味着更多的日志文件。
以上就是采用微服务前需要思考的一些问题，也欢迎你在评论区留下自己的看法
来源：住手！！你不需要微服务！