问微型服务和生产正常运行时间

EN

现在，假设一家公司实施了微服务，每个团队都负责自己的微服务。

这是个谬论。一家公司可能实现来自不同团队的许多服务，但它是一个单一的生产团队将负责保持它的运行。这意味着开发团队必须提供足够的文档和/或工具，以确保他们能够完成他们的工作。这和其他建筑没什么不同。

另一方面，您不能使用microservices集中操作，因为每个微服务可能有不同的技术堆栈、不同的故障排除和监视方法。

当然，但这也意味着，保持其运行的文档需要比开发团队使用现有工具生成的标准系统更完整(因为“基线”平台已经被理解，因此不需要重新记录)。

无论如何，大多数企业只会在标准架构上开发，如果您是一个.NET商店，发布Rails服务的团队就会被忽视(如果允许他们首先交付这样的服务)。

维护的另一个方面是，企业也将有标准的监视要求。因此，生产团队会说，他们希望看到某种格式的日志，以及某个模板中的错误报告等。虽然这无助于购买第三方服务，但它确实大大降低了维护成本。

简而言之，对于开发团队来说，微型服务并不是随心所欲地抛弃现有的标准，做他们本周想做的任何事情。服务在现有环境中工作的要求仍将在原始请求中指定。

Microservices比其他重量级的服务(如JSF、ROR、MVC、CORBA或其他企业技术缩写)要简单得多。简单意味着更容易维护和继续运行。Node.JS和NoSQL也是向更简单、更解耦的体系结构发展的趋势的一部分。

然而，在决定是否使用微服务时，维护并不是唯一的考虑因素。正如您正确指出的那样，微服务本身就增加了复杂性：

大多数公司不需要微型服务。马丁·福勒：

甚至不要考虑微服务，除非您的系统过于复杂，无法作为一个单一的系统来管理。大多数软件系统应该作为单一的单块应用程序来构建。一定要注意单体内部良好的模块化，但不要试图将其分离成不同的服务。

真正的挑战是将异构组件集成到一个连贯的系统中，但这种情况一直都是如此，可以通过让所有的微服务都符合REST体系结构和微服务所鼓励的组件的一般简单性来简化这个问题。

微服务和SoA在总体上是很酷的，但它们确实依赖于一个全面而有弹性的基础设施。

如果您没有得到足够的故障转移，您仍然需要工程师出来，在凌晨3点，当一些故障，你可能有更多的工作要做在这个领域！

在我看来，这不是‘服务器X已经崩溃紧急！’您需要担心这个体系结构，因为这可以通过传统的故障转移和冗余来处理。

这是丢失的消息和微服务之间的中断编排，这是对传统设置的真正额外的痛苦。“0.3%的顾客在时钟前进时没有收到订单！”或者“以Z起家的产品不适用价格调整！”wtfs是你的新噩梦