您不会做微服务

好像我们行业每隔5到10年，尤其是在企业集成或企业应用程序领域，我们被引入了一些新的方法或体系结构样式，这是自切面包以来最好的方法，它将使您的生产率提高10倍，并使您的企业更加敏捷，灵活，能够响应变化，以及CIO愿意花费大量金钱的其他任何东西。 我们已经看到了企业应用程序集成，Web服务，SOA，基于组件的体系结构，ESB等。

今天：微服务

好吧，猜猜是什么：您可能不会正确使用微服务架构。

老实说，我并不是说要出于您渴望尝试新事物的渴望而倾倒冷水。 我确实认为微服务具有合法性，并且这种方法在多年来观察失败的委员会驱动的实施过程中有机地增长了。 但猜猜怎么了？ 必须首先具备先决条件的基础，才能成功使用此架构（或任何架构） ），根据我的观察，目前缺少的地方比目前流行的地方多。 一定要启动Spring Boot或Dropwizard，或者不启动任何容器。 您不是在做微服务，只是因为您正在远离App Server进行跟踪 。 像Netflix，Amazon之类的地方似乎具备一些使其必不可少的先决条件才能使之正常工作……但是，请问您的工程副总裁，问您的计算主管，如果他们的内部团队像Amazon那样组织，他们会怎么说。 他们会宠坏他们的裤子。 您的公司可能不会，也可能不会正确地使用微服务。

大多数组织不是为微服务构建的

我们都听说过康韦定律，但这是您不打算做微服务的最重要原因。 人赢了。 文化取胜。 纸张流程和纸张结构无法取胜。 如果您有一个UI团队，一个DB团队，一个“服务”团队，每个团队都有自己的专长，那么您最终将获得类似于这些层的系统。 这些本质没有错。 但是，以技术为团队的团队之上的树形结构和层层管理人员是基于微服务的团队的障碍。

REST不是灵丹妙药

REST很棒！ 我喜欢这些概念，对于企业来说，它基本上就是我们所讨论的HTTP实现。 我很高兴摆脱SOAP。 HTTP和REST被理解，具有强大的工具，网络设备，代理等，都牢记在心……但是REST并不是灵丹妙药 。

模块化应用程序很难

服务应该多大？ 应该有多深？ 单一职责？ 域驱动设计有界上下文等。在实践中，这都是很难做到的。 多次这样做并失败是学习（如何避免）尖锐边缘的最佳方法（我认为），但是正确地模块化应用程序和域服务并不容易。

我们仍然不了解如何做基于事件的架构

为什么我们仍然通过RPC连接所有内容！！！？ 这使我感到最恼火的是，我们仍然不知道如何正确地进行事件驱动的体系结构，并且当“新的”体系结构样式出现时，我们重温了与上一个相同的所有错误。 顺便说一句...。 微服务！= REST。

好的，这有点令人不快，但只是想为围绕微服务的讨论带来一些现实。
归根结底，在流程级别隔离“服务”或系统仍然不是真正松散的耦合或“解耦”系统。 运行时耦合仍然非常存在，甚至可能更多。 没关系，分布式计算的谬论仍然成立。 因此，也许当我们重新发明建筑风格时，会在吸取的教训中加以构架吗？

翻译自: https://www.javacodegeeks.com/2015/02/youre-not-going-to-do-microservices.html