当我开始了解《微服务架构》的时候，我发现里面的中文文章是相当的少，于是开始试着翻译一些文章，比如这一篇《微服务——不是免费的午餐》。这篇文章是在某次讨论结束后听到的，和之前类似的是这种区别有点类似于之前说的微内核与宏内核的区别。

译文如下:

文章是由Contino公司的CTO，Benjamin Wootton写的。Contino是一家在伦敦的咨询公司，专注于DevOps和持续支付。

Microservices are a style of software architecture that involves delivering systems as a set of very small, granular, independent collaborating services.

微服务是一种软件架构——那些传递系统是一组非常小的、粒状的(granular)、独立的协作服务的集合。

虽然他们不是一个特别新的想法，微服务似乎已经深入人心了，而在今年正好爆发了，有论文，有会议，以及Twitter上对于建立这种风格软件系统的好处的讨论。

这种普及是顺应趋势的，如云计算、DevOps和持续交付等走到一起作为推动的。以及部分的好的应用在一些场景上，如Netflix采用这应用模式有很大的明显效果。

微服务架构有很多非常真实和显著的好处。

• 服务本身是非常简单的，每个服务侧重于做好一件事;
• 可在这个位置使用最佳和最合适的工具来构建每个服务;
• 建在这样的系统本质上是松耦合;
• 多个开发者和团队可以彼此相对独立的提供这种模式下;
• 他们是一支伟大推动者连续输送，让频繁的发布，同时保持系统的其余部分可用的和稳定的。

这也就是说,微服务不是免费的午餐!

我目前正在参与围绕微服务的架构设计，而各种个服务都非常简单，非常复杂的地方在于——用一个更高的水平去管理这些服务和管理业务流程之中。

微服务在实践中是一个好主意，当所有复杂度出现的时候它符合当前。出于这些原因，我想写和篇文章，想写这篇文章来捕捉这些和平衡他们。

显著的运营开销

一个微服务架构带来了很多操作上的开销。

当一个宏应用程序(相比于微内核与宏内核，这里用宏应用，微应用加以区别)可能已经部署到一个小的应用程序服务器集群，你现在有几十单独的服务来构建，测试，部署和运行，有可能在多语种的语言和环境

所有这些服务可能需要群集故障转移和恢复能力，将您的简单宏系统添加进去，比如说:20个服务，包括40-60处理后，我们已经添加了弹性。

把负载平衡器和消息层的服务和estate(不知道怎么翻译)开始之间的管道变得非常大时相比，单片应用带来相当的业务功能！

产品上的所有这一切都需要高品质的监控和操作的基础设施。保持一个应用程序服务器上运行可以是一份全职工作，但我们现在必须确保几十甚至上百道工序熬夜，不要运行磁盘空间不足，不死锁，保持高性能。这是一个艰巨的任务。

物理上的运输大量的多如牛毛微服务，通过管道进入生产也需要一个非常高的程度的鲁棒性和发布和部署自动化。

目前，从操作的角度来说，没有太多的框架和开源工具可以支持。很可能，因此，一个团队推出了微服务将需要在自定义脚本或发展显著投资来管理这些流程他们写一行代码，提供商业价值之前。

操作是对模型中最明显和普遍持有异议，但实在是太容易被这种架构的支持者置之不理。

大量的开发运营(DevOps)技术要求

在一个开发团队可能就有这个问题，当你的团队保持一个Tomcat集群可用，这就意味着你肯定需要高品质的DevOps和自动化技术融入到你的开发团队。

你不能把建立在这种风格在墙上来运营团队的应用。开发团队需要集中于可操作和生产意识，作为一个微服务的应用程序是非常紧密地集成到它的环境背景。

这种架构的使用习惯也意味着许多的服务也需要他们自己的数据存储。当然，这也可能是通晓多种语言的人（用于工作的正确工具），这意味着古老的DBA现在需要更换开发者有很好的了解如何部署，运行，优化和支持少数NoSQL产品。

如果你走上这条道路，你要面临的招聘挑战更更困难，因为具有较强的DevOps技能的开发商是很难找到的。

隐式接口

一旦你打破一个系统进入协作组件，你介绍它们之间的接口。接口充当合同，双方需要交换相同的消息格式和拥有这些消息的同一语义理解。

更改语法或语义上的某一侧，所有其他服务需要了解这种变化。在微服务的环境中，这可能意味着简单的跨领域的变化最终需要改变许多不同的组件，都需要被释放的协调方式。

当然，我们可以避免一些变化与向后兼容性的方法，但你经常会发现，一个业务驱动要求禁止上演的版本呢。发布一个新的产品线或实例的外部强制监管的变化能够迫使我们的手来释放大量的服务一起。这代表了由于积分点的替代单片应用额外的释放风险。

如果我们让服务合作向前发展，成为不同步，也许在金丝雀释放的风格(译注:“金丝雀部署”是增量发布的一种类型，它的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。)，改变消息格式的效果会变得很难想象。

再次提醒， 向后兼容性不是万能，这里是微服务传道者所声称的程度。

重复努力

试想一下，有一个新的业务需求不同，以计算税款一定的产品线。我们如何提供这有几个选择。

• 我们可以引入一个新的服务，并允许其他服务在需要的地方调用他。然而，这引入更多的潜在的同步耦合进入系统，所以并不是我们随意决定的。

• 我们可以重复努力，加上税计算到所有需要它的服务。除了重复开发工作，重复自己，而这种方式通常被认为是一个坏主意，因为代码的每个实例都需要进行测试和维护前进。

• 最后一个选项是共享，如服务之间的税务计算库资源。这可能是有用的，但在一个多语种的环境中，它并不总是可行的，并引入耦合这可能意味着服务，必须在发布的同时保持它们之间的隐式接口。该耦合本质上减轻了很多的微服务的方法的好处。

在我看来，所有这三个选项是次优的，而不是写一段代码一次，使它可在整个单片应用程序。我已经看到了这种风格的工作团队倾向于选项2 ，重复的业务逻辑，这违背了良好的软件工程的很多原则。是的，这甚至发生在井分解和设计的系统 —— 它并不总是坏的服务边界的标志。

分布式系统的复杂性

微服务意味着这是一个分布式系统。而在此之前，我们可能有一个方法调用作为一个子系统的边界，我们现在引进大量的远程过程调用REST API或消息来跨越不同的进程和服务器组件粘合在一起。

一旦我们的系统是分布式，我们要考虑的东西比我们之前的多得多——网络延迟，容错，消息序列化，不可靠的网络，异步性，版本控制，在我们的应用程序层等不同的负载.

编码其中的一些是好事。向后兼容性和优雅降级是可以拥有的不错的属性，我们可能没有在单片应用他们，会帮助保持系统，比宏应用具有更高的可用性。

这样做的成本却是应用程序开发人员必须考虑所有这些事情，他们没得之前。分布式系统是一个数量级，更难以发展和对测试，再次提出与建筑，酒吧是令人讨厌的宏应用。

异步性的困难性

有关上述点，建于微服务式系统很可能会比单一应用程序更加异步的，依靠于消息和并行性来提供他们的功能。

当我们可以工作分解成它可以发生乱序在不同的时间真正独立的独立任务，异步系统是好的主意。

然而，当事情已经同步或事务性发生在一个固有的异步架构，事情就变得复杂与我们需要管理的相关ID和分布式事务，以配合各种共同行动。

可测试挑战

这么多的服务都在的以不同的速度变化和不同的服务，不断推出的金丝雀(译注:在生产中使用金丝雀部署来进行测试)的版本内，它可能很难重新以一致的方式进行手动或自动测试。当我们添加的异步性和动态消息负载，它变得更难测试建立在这种风格的系统的安全并获取信心的一组服务，我们将要释放到生产。

我们可以测试单个服务，但是在这个充满活力的环境中，很微妙的行为可以从它们很难想像和揣测服务的交互出现，更不用说全面测试。

地道的微服务包括放置不太重视测试和更多的监管，我们可以发现异常的生产和快速回滚或采取适当的行动。我在这个方法一个很大的信徒 - 低障碍，释放，为了加快精益交付靠在持续交付。然而，正如有人也花了几年应用的自动化测试，为了在获取在release之前的信心，任何降低这种能力感觉就像一个高昂的代价，尤其是在风险规避监管环境中的错误可以有显著的影响。(转载保留微服务架构——不是免费的午餐)

结论

这些都是我在建设的初期阶段看到并运行一个微服务为基础的系统的困难。

我还是进场的球迷，相信在合适的项目与合适的团队这是一个美妙的建筑采用其中的好处大于上述成本。

然而，考虑到微服务架构一样的时候，它真的很重要，不能在这一个吸引到炒作的挑战和成本是一样真实的好处。