微服务架构——不是免费的午餐

Posted 2020-09-11 gavanwanggw

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

译文例如以下:

文章是由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採用这应用模式有非常大的明显效果。

微服务架构有非常多非常真实和显著的优点。

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

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

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

微服务在实践中是一个好主意。当全部复杂度出现的时候它符合当前。

出于这些原因，我想写和篇文章。想写这篇文章来捕捉这些和平衡他们。

显著的运营开销

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

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

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

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

产品上的全部这一切都须要高品质的监控和操作的基础设施。保持一个应用程序server上执行能够是一份全职工作，但我们如今必须确保几十甚至上百道工序熬夜，不要执行磁盘空间不足，不死锁，保持高性能。这是一个艰巨的任务。

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

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

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

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

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

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

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

假设你走上这条道路。你要面临的招聘挑战更更困难，由于具有较强的DevOps技能的开发商是非常难找到的。

隐式接口

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

更改语法或语义上的某一側。全部其它服务须要了解这样的变化。

在微服务的环境中，这可能意味着简单的跨领域的变化终于须要改变很多不同的组件，都须要被释放的协调方式。

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

假设我们让服务合作向前发展，成为不同步，或许在金丝雀释放的风格(译注:“金丝雀部署”是增量公布的一种类型。它的执行方式是在原有软件生产版本号可用的情况下。同一时候部署一个新的版本号。

同一时候执行同一个软件产品的多个版本号须要软件针对配置和完美自己主动化部署进行特别设计。)，改变消息格式的效果会变得非常难想象。

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

反复努力

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

• 我们能够引入一个新的服务。并同意其它服务在须要的地方调用他。然而，这引入很多其它的潜在的同步耦合进入系统，所以并非我们任意决定的。

• 我们能够反复努力，加上税计算到全部须要它的服务。除了反复开发工作，反复自己。而这样的方式通常被觉得是一个坏主意。由于代码的每一个实例都须要进行測试和维护前进。

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

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

分布式系统的复杂性

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

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

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

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

异步性的困难性

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

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

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

可測试挑战

这么多的服务都在的以不同的速度变化和不同的服务。不断推出的金丝雀(译注:在生产中使用金丝雀部署来进行測试)的版本号内，它可能非常难又一次以一致的方式进行手动或自己主动測试。

当我们加入的异步性和动态消息负载。它变得更难測试建立在这样的风格的系统的安全并获取信心的一组服务，我们将要释放到生产。

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

地道的微服务包含放置不太重视測试和很多其它的监管。我们能够发现异常的生产和高速回滚或採取适当的行动。我在这种方法一个非常大的信徒 - 低障碍，释放，为了加快精益交付靠在持续交付。

然而。正如有人也花了几年应用的自己主动化測试，为了在获取在release之前的信心，不论什么减少这样的能力感觉就像一个高昂的代价，尤其是在风险规避监管环境中的错误能够有显著的影响。

(转载保留微服务架构——不是免费的午餐)

结论

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

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

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