站务联系
好的后端开发很难。扩展后端开发，使许多团队可以同时处理小型复杂产品，这显得格外困难。在本文中，我们将描述将后端整体分拆成许多更小，更易管理的片断的最新趋势，以及该机制结构怎样增加处理后端代码的团队的效率跟效率。在讨论各式回报跟费用的同时，我们还将介绍一些可用的实现选项，并且将深入研究一个演示该技术的完整样例应用程序。
近年来，微服务已快速普及，许多组织都使用这些构架色调来防止小型，整体前端的局限性。尽管有关建立服务器端硬件这些色调的文章已太多，但许多公司仍在与整体式后端代码库作斗争。
也许您想建立一个渐进式或响应式Web应用程序，但是找不到一个轻松的地方来开始将这种功能集成至现有代码中。也许您想开始使用新的JavaScript语言功能（或可以编译为JavaScript的多种语言之一），但是您未能在现有的建立过程中使用必要的建构工具。或者，也许您也是想扩充您的开发，以便多个团队可以同时处理一个产品，但是现有整体中的耦合跟复杂性意味着每位人都在相互踩腿。这些都是真正的问题，都会对您有效地向顾客提供高质量感受的能力形成负面影响。
最近，我们看见越来越多的注意力集中在复杂的现代Web开发所必需的总体机制结构跟组织结构上。特别是，我们听到了将后端整体分解为更小，更简略的块的方式，这些块可以独立开发，测试跟布署，同时依然对顾客而言是一个具备凝聚力的产品。我们称这些技术为微后端，我们将其定义为：
“一种构架色调，可独立交付的后端应用程序组成了一个更大的整体”
在ThoughtWorks技术声纳的2016年11月号中，我们列举了微后端作为组织应评估的一种技术。后来我们将其推广至试用版，最后推广至选用，这意味着我们觉得它是一种行之有效的办法，应在合理的状况下使用。
当然，涉及硬件机制结构时不会有免费的晚餐-一切都是有代价的。一些微后端实现或许造成依赖关系重复，从而提高了用户应当下载的字节数。此外，团队自主权的大幅降低可能会造成团队工作方式分散。尽管这么，我们觉得可以控制那些风险，而且微后端的回报常常超出费用。
好处
我们没有根据特定的技术技巧或施行细节来定义微观后端，而是将重点置于了出现的属性跟他们带给的弊端上。
增量升级
对于许多组织而言，这是其微后端之旅的开始。过去的技术堆栈或在交付压力下撰写的代码妨碍了旧的，大型的后端组件的发展，目前正进行着完全重画的尝试。为了防止完全重画的危险，我们更希望逐项抹杀旧的应用程序，与此同时，继续为我们的顾客提供新功能微端服务器，而不会遭到整体功能的影响。
这一般会导致构建微后端构架。一旦一个团队经历了将功能仍然投入生产且几乎不对旧世界进行任何更改的经验，其他团队也将希望加入新世界。仍然须要维护现有代码，在这些状况下，继续为其添加新功能或许是有意义的，但是目前可以选择了。
最终的结果是，我们有更大的自由可以对产品的各个部份进行逐案决策，并对我们的体系结构，依赖关系跟用户感受进行增量升级。如果我们的主框架发生了重大的重大变化，那么每位微后端都可以在有意义的时侯进行升级，而毋须被迫停止世界并立刻升级所有内容。如果我们想尝试新技术或新的交互模式，则可以比原先更孤立的形式进行。
简单，解耦的代码库
根据定义，每个单独的微后端的源代码都将比单个整体后端的源代码小得多。这些较小的代码库对于开发人员而言更趋向简略跟容易。尤其是，我们防止了互相不了解的组件之间无意跟不适当的耦合所造成的复杂性。通过在应用程序的有界上下文周围描绘粗线，我们让这些碰巧的耦合显得格外困难。
