让我们看一个公司/客户与前端框架技术团队之间的典型对话。
这是你从公司/客户那里听到的，技术团队因此而疯狂。当整个世界都从微服务中获益时，为什么不应该采用微服务，技术团队很难说服决策者。
让我们看看微服务的各种开销和缺陷。除了处理核心应用程序之外，还需要解决所有的这些问题。
微服务的开销
-
业务间的通信是一大挑战
-
服务发现和注册
-
负载均衡
-
去中心化数据管理
-
分布式日志
-
监控
-
安全
-
测试
-
性能／指标
-
分布式事务
-
容器——Docker/Kubernetes
-
API网管
-
熔断
-
CI/CD和DevOps
-
其他...
微服务根本不适合每个人。 我们中的一些人在权衡了复杂性与利益之后，决定继续使用单一架构。 不能因为每个人都跳桥，结果你也往下跳。
微服务只是个选项。如果不做微服务，您仍然可以实现您的目标。
这些问题需要回答。
-
为什么你想转向微服务？
-
你想得到什么好处？
-
你的组织准备好结构和文化变革了吗？
-
你的公司是否已有工程技术经验？
-
那打算迁移多少？什么时候停止？
-
这样做的好处大于成本吗?
让我们看一下不应该选择微服务的各种场景
场景1：小团队
只有少量成员的小团队无法使用微服务加快速度。 组织需要一定的临界质量来承受微服务的细微差别和开销，然而，就单体应用而言，一个由极少数员工组成的小团队就可管理，维护和运营一个稳定，体积适中的应用程序。
场景2：组织结构和文化
无论最初的应用是否是模块化的，而微服务化后的架构都将会导致模块化。几乎所有的软件架构拥护者都会同意，这是一个非常好的结果。由微服务们所创建的服务将是自包含的和独立的。
康威定律(Conway's law)规定，“任何设计系统的组织（这里只是更广泛地定义信息系统）将不可避免地产生一种设计，其结构是组织通信结构的副本。”从该定律可以理解，传统架构只是其孤立和分层组织的副本。随着组织的发展，决策者不断在他们的团队和控制下增加更多的人员作为一种力量的表现，所有的沟通都通过他们。
相比之下，微服务的实践者建议，为了成功，团队应该小（可能少于 10 人）和独立。团队应该与同一团队中的开发人员、测试人员、数据库和运维人员进行交叉功能。他们应该负责应用程序的所有方面，包括可用性、可伸缩性、性能等非功能性方面。
如果组织结构不像这样，他们甚至不应该考虑转向微服务。这应该是基于微服务的体系结构的第一个先决条件。
场景3: 试图证明商业理念 Poc 的初创公司
对于成功的产品来说，初创公司 —— 或任何组织 —— 就此而言，有时会做几个 PoC 来测试对产品、市场需求、业务场景或技术需求。在充分投入到这个想法的研发之前，需要验证一个商业理念。无论何时完成，组织都需要以极快的速度快速行动。在这种情形下，完整的微服务架构可能不是一个好选择。建议将整个应用程序用作为 PoC，然后慢慢将其转换为微服务。
场景4: 非工程类组织
如果你在一个不以工程为核心的终端用户组织中，那么如果你采用微服务则其实是不利的。在一天结束时，所有商业组织都在那里赚钱的。如果你不专注于为客户创造价值，并且深陷架构的细节和开销中，那这绝对不适合你。冒险之前要三思。
改变的原因
到目前为止，你必须明白和确定你选择微服务架构的真正原因。让我们来聊聊你会考虑选择什么的一些场景。
-
如果整个应用程序或所有服务具有需要被布署为独立单元的性质，那么设计不良的微服务应用程序可能会使情况恶化。
-
以前不成功的单体应用程序：如果设计一个单体应用程序对于团队来说是一个挑战，那么微服务应用程序肯定会失败。
-
你有一个遗留的应用程序，预计最终会弃之不用。移植遗留下来的单体应用需要大量的时间和精力，这可能并不值得。
-
如果一天只是多次扩展和布署UI，则可以将UI部分单独提取出来。然后将这一部分扩展并布署到单独的容器中，使用某种API访问后端应用程序。再说一遍，不需要将所有的东西都放到微服务中
-
一个功能或服务似乎总是在加载和需要扩展。
如果你只需要扩展一个或很少的几个服务，则不是使用所有的组件来扩展整个单体应用，那么迁移到微服务可能就是一个真实可行的案例。但是，有办法避免它。一种方法是从单体应用中提取这些服务，并将它们分别托管在不同的容器中。这不仅有助于扩展它们，而且可以帮你不会将整体迁移到微服务中。
重申一遍，这里并不是在阐述单体应用或SOA或微服务。是在阐述合适的架构来满足业务需求。如果不需要去处理微服务的开销就可以增长并获得所有的收益，那为什么还要去考虑它？你可以根据需要慢慢添加更多的服务。在你真正需要或想要它之前，没有人会强迫你。
结语
我们已经探讨了微服务架构的各种细微差别和开销。它绝不是这样一种简单的模式，如果它不生效，它不可以很容易地被采用和丢弃。在将组织推向微服务道路之前，需要考虑所有的优点和缺点。人们需要关注“为什么是微服务”，而不是“为什么不是微服务”。 我们还探讨了各种方案。这是为了避免在绝对必要之前涉足微服务的各种复杂性。
同样，你可能不同意我的一些或所有意见，但我很高兴我们今天可以探讨这个问题。
引用: