有一种感觉，微服务通常被定位为替代整体的“银弹”。但并非每个人都喜欢这种方法。实际上，有时会错误或不正确地使用它。以下是在不同公司中使用微服务时我很幸运遇到的问题的示例，我以后不想重复。
幻影可扩展性
微服务方法的大胆优点是可伸缩性。无限大的用户流量和高负载被认为是不可避免的。因此，大量时间用于初步优化，而不是有用的业务功能。实际上，并不总是存在高负载。
预优化的第一个受害者是线性业务流程。它分解为许多微服务。由于职责分工或虚幻的扩展，对未来的一种储备。结果，企业在IT环境中导航和说与IT使用相同的语言变得更加困难，更不用说为开发人员自己浏览源代码了。
服务互动问题
收到的服务从monorep分散到单独的存储库中。服务本身变得越来越难以链接在一起。在这种情况下，微服务API的版本可能开始与微服务客户端中相同API的版本不同。然后，将旧的JSON替换为Protobuf，将HTTP替换为gRPC，以获取性能，输入和方便的API版本控制。
不幸的是，像gRPC + Protobuf这样的解决方案不能保证没有错误。由于错误的传播和服务输入输出对的已知不匹配，服务可能会顺序下降。代码库越来越大，服务的调试要比纯文本数据复杂得多，从而带来了新的问题。
此问题应通过正常的测试过程解决。特别是集成测试。但是，需要为业务流程中的每个微服务及其组编写并运行集成测试。这是一项相当困难的任务，他们通常不希望分配额外的时间。在这种情况下，微服务集成测试可以简化为整体的单元测试形式。
旧的限制和习惯
有了所有这些，对整体的通常限制就进入了微服务。引人注目的示例：所有微服务的一种编程语言和一个数据库。在第一种情况下，这是整体结构的先前限制，在第二种情况下，这是努力成为整个系统的“瓶颈”的传统。由于开发人员和管理人员不接受使用不同编程语言构建的异构系统的可能性，因此失去了选择合适的工具来解决紧急问题的可能性。
除上述之外，单个微服务可能没有开发人员对此负责。每个人都开始支持一切，没有人对任何事情负责。在这种情况下，除了最后一个更改代码的人之外，没有人对单个服务的操作有所了解。开发人员的同步性下降，对与主题领域内解决的任务相关的微服务工作本质的了解不足。
基础设施官僚主义
微服务比整体服务难维护。曾经是一对服务器的基础架构变成了一个小型私有云。开发人员需要大量时间来支持此类解决方案，并在将来为管理带来麻烦。对于额外的官僚机构而言，存在牵强的需求。雇用个人员工，创建单独的流程。
在这种情况下，可以公开使用微服务的规则集以维护微服务循环的完整性。最坏的情况是甚至不允许运行一次性脚本或迁移，而又不允许直接访问电路。最重要的是，该脚本的样式被定义为一种成熟的服务，在长长的微服务列表中又增加了一行。
未来
结果是系统产生的噪声比有用信号高出许多倍。无处不在-从基础结构到特定服务的代码。从开发人员对服务交互方案的理解到公司的管理。程序员不经意间成为解决难题的大师。
当然，经典的整体设计并没有更好。它速度慢，保持其状态，难以处理，不受单元测试或集成测试的影响等。但是我们可以做得更好！由于微服务的流行，我们看到CI / CD的上升以及许多其他积极因素，因此我们进行了测试。现在，我们可以将它们应用于其他方法，而不仅仅是微服务。
下次开发新系统或回收旧系统时，无论它有多大，都请考虑一下。公司需要可扩展性吗？您是否需要处理高负载的能力？您是否真的为微服务做好了准备？还是从更保守的架构开始更好？
也许不是建造火箭，而是建造一辆简单的踏板车，因为您只需要到达街道的尽头？