这是技术雷达系列文章的第四篇。在这一系列的文章中，技术雷达的作者们向企业领导者分享了他们对于那些推动业务差异化的技术问题和解决方案的洞见和经验。ThoughtWorks技术雷达是由ThoughtWorks全球技术专家咨询委员会创建的，它包含了对软件开发和业务战略有显著影响的技术趋势组合，2016年是技术雷达发布的第七年。
未来已经在这里，它只是分布不均。- 威廉·吉布森
数字时代就在我们身边。将软件开发视为高成本开销而不是竞争力的企业将会艰难前行。为了参与并在这个数字世界中繁荣兴旺，企业必须学会适应我们这个时代的不确定性—更快地将新产品推向市场，快速而有效地加强当前的产品，并为客户提供有意义的数字体验。
为了实现这些目标，企业需要将敏捷性/适应性集成到三个领域：人，流程和技术。
人们需要适应试验和改变。过程需要迭代式进行并加强学习。技术，包括技术架构，需要能够支持快速地交付产品与服务。
技术的敏捷性不能被忽视——敏捷的团队和流程并不能弥补笨重的技术。
但作为一个高级管理人员，在这样一个充满了新技术的世界，你应该注意些什么技术呢？
这个问题的答案被那些不停地讨论看似神秘话题的技术人员们所掩盖。哪些神秘的话题需要得到管理层的注意呢？其中最重要的话题之一是微服务。其中的原因如下所述：
微服务影响人，流程和技术：包括团队组织结构，流程和实践（如DevOps），以及重新调整架构以适应我们要解决的问题，而这些并非在技术层面。微服务促进了每个领域的适应性。它值得管理层花时间去了解潜在的贡献。
技术敏捷度
微服务架构风格的特性是由一组极小的服务组成，它们彼此互相独立且单独部署。微服务由Netflix这样的公司推广开来。每个服务包含一个离散的业务功能，它在技术上与其他服务相隔离，产生了类似乐高积木的效果：开发人员可以将服务切换为一个新的服务，而无需破坏其他服务。就像巨型的乐高模型可以有75,000块乐高，大型的数字应用程序也可以由这些受乐高思想启发的服务所构建。
这种架构有一些明显的好处。首先，每个服务与其他服务高度解耦，这意味着它们是自包含的。因此，一个服务中的技术更改（例如数据结构更改）不会影响另一个服务。服务仍然可以通过消息传递进行通信，但是任何一个服务都不允许修改另一个服务的实现细节。
第二，因为开发人员不需要共享基础设施，他们可以选用适合于该问题复杂度的技术栈来实现每一个服务。考虑到当今技术栈的复杂性，在同一应用程序中，使用简单工具处理简单问题和使用复杂工具处理复杂问题的能力使开发团队增加了灵活性并降低了成本。领导者重视能将复杂问题简化的技术专家。
第三，每个服务封装了业务功能，它使得形成围绕特定问题域的团队更容易，而不是通过作业功能分割的团队。例如，服务团队通常包括开发人员、业务分析师、DBA、运维人员和QA—即构建和部署服务所需的一切角色。而这反过来减少了协调成本。
从功能性组织结构向产品或服务结构转变是敏捷企业转型的一个日益增长的趋势。而微服务架构支持了这种趋势的变化。
最后，因为每个服务是相互隔离的，所以以服务组成的架构既快速又灵活。同时因为服务的业务范围很小，对服务的更改可以快速地发生，这为开发人员提供了新的高级功能。一旦架构师设计了一个小型独立服务的系统，其中应用程序由部署的多个服务之间的消息传递组成，多变量测试等能力就变得容易了。
例如，企业可能对他们网站的未来方向并不确定。因此他们设计了具有相似但不同功能的两种服务，并向不同的用户组部署不同的版本，以获取结果从而推动未来发展的方向。像Facebook这样的公司也是通过使用这种类型的A / B测试进行试验来分析他们的用户。
标准化一直是IT组织作为降低成本方式之一的口头禅。不幸的是，它也降低了灵活性—标准化越多，灵活性越少。通过采纳微服务架构，架构师和开发人员可以使用更加多样化且能够紧密反映问题复杂度的技术栈来设计应用程序。
微服务架构风格与许多企业部署软件和分配IT资源的方式相反。许多架构风格的主要目标之一是有效地利用共享资源（操作系统、数据库服务器、应用程序服务器等）。由于资源的成本影响了底线，因此这些公司建立了软件架构以最大化共享资源。
然而，共享资源有一个缺点。无论开发人员如何有效地构建与这些服务器的隔离，都会出现对这些资源的竞争。有时组件由于依赖管理而互相干扰，有时由于两个组件争用某些资源（例如CPU）而产生问题。这就不可避免地引起共享组件以并不期望的方式进行交互。
容器和解耦
在软件交付中，有两个关键的技术“环境”：开发人员工作的开发环境，以及IT运维人员管辖范围的部署环境。传统情况下，在这两个环境之间移动代码充满了技术错误，冗长的时间延迟以及组织层面的沟通不畅。
几年前，一些有趣的事情发生了：Linux对于大多数企业足够友好，Linux的变体在商业上免费—但是这不足以影响技术架构。
接下来，开源的创新与敏捷开发技术的结合鼓励了开发人员创建各种工具，将许多繁琐的运维手工操作自动化。这被许多人称为DevOps革命。
这场革命使得开发团队和IT运维人员通过使用Puppet、Chef和Docker等高级工具更加紧密地联系在一起。意外地，Linux的变体允许免费操作，开发人员可以将其组件部署到一个原始的操作系统，没有别的干扰因素。一整个可能的错误类别就突然消失了，因为组件之间相互解耦。
如果开发人员可以构建他们自己的现实环境，他们必须减少与运维部门的协调，从而减少了组织间的摩擦。用程序启动类生产环境的能力消除了测试、集成、共享环境下的资源竞争、以及一系列其他问题。
21世纪的架构敏捷度
在治理方面，微服务架构风格有其他的好处。传统的做法是，企业架构师定义了组织的共享技术栈，以最大化项目间的资源使用，同时最大程度地减少支撑成本。例如，一个大型企业可能将Java和Oracle标准化以作为其主要开发平台。如果每个人都使用Oracle，那么该企业的一切都可以存储在一个工业强度的数据库中。
规范化治理有一个缺点—通常，为了标准化的某一目的，团队必须使用并不太理想的工具。但还有一个潜在的更微妙的缺点。例如，考虑一个已经选择在特定消息队列上标准化的大型企业。在评估需要此共享基础设施的所有项目时，企业架构师会找出最复杂的场景，并选择一个适合这种复杂度的工具来处理它们。
然而，许多项目并不具备这个最复杂的场景。但因为每个项目必须共享相同的基础设施，所以每个团队承担了其他团队的最大复杂度。这也发生在数据库层。许多项目只需要一个有几个记录的简单数据存储，并不需要复杂的查询功能，但最终都使用了具有工业强度的数据库服务器，只因为它是这个企业的标准。
容器化技术解决了这个问题，因为它远离了共享基础设施—每个项目都部署在他们自己原始的、容器化的环境中。因为不存在共享的动力去选择工具，所以每个项目刻意选择更适合自己的工具。
当然，如果企业架构师允许每个项目选择自己的技术栈，那么会存在一些严重的缺点。我们经常看到一个称之为““Goldilocks治理”（企业架构师选择几个技术栈—简单、中等和复杂，并根据规模分配新项目）的实践，它适用于高度解耦的环境。这些知识是可迁移的，该公司仍然可以从中受益，但是却可以远离那些由于疏忽大意而将问题过于复杂化的行为。
为什么我们会谈到这儿？
Eric Evans的“领域驱动设计”一书是对微服务架构的另一个巨大影响。它是一种将大问题空间分解为领域或重要实体（如客户和订单）及其关系（客户下订单）和行为的技术。领域定义的一部分是有关边界上下文的概念：每个领域形成一个围绕实现细节的封装层。
例如，如果分析人员识别了一个Customer领域，那么它存在于自己的边界上下文中。在Customer的上下文中，开发人员知道所有的实现细节：类结构，数据库模式等。
但是，其他边界上下文（如Orders）不能看到这些实现细节。虽然领域可以为了协调的目的互相发送消息，但是任何一个领域都不能穿透另一个的边界上下文。因此，在一个边界上下文中的开发人员可以自由地更改实现，而不必担心破坏其他领域。
微服务中的容器是领域驱动设计（DDD）中边界上下文的物理表现：每个容器代表了一层封装，以防止实现细节干扰系统的其他部分。边界上下文提供的隔离展示了结构化软件架构的不同方式。
在过去，设计架构主要围绕技术架构：架构模式，库，框架等。例如，分层架构在许多组织中是很常见的：
图1: 传统的分层架构
在图1中，架构师沿技术层进行分离，使得在需要时可以容易地替换一整层的内容。例如，如果开发人员需要更改持久机制，所有相关代码都会出现在持久层中。
那么开发人员多久更换一次整个持久层呢？几乎从不。但你的团队多长时间基于像Customer这样的概念工作呢？每天！
在图1分层架构中，Customer处于哪一层呢？其中部分在表示层，业务层，持久层等等。因此，项目架构上通用单元的变化在分层架构中并没有得到很好的支持，原因是通用的变更影响到了每一层。
如果不同层代表了开发团队的不同部分，其影响会更严重。例如，对Customer的更改可能需要更改用户界面，业务逻辑，持久层和其他特性。如果你的组织有开发人员，DBA，用户界面设计师和运维人员组成，而他们在相互隔离的HR部门下，那么进行常见更改的协调成本是巨大的。
微服务强调解耦和容器化，翻转了图1中的传统做法，使领域成为架构的主要元素，如图2所示。
图2：以领域为中心的架构
在图2中，分层结构仍然存在，但是其耦合边界是领域的边界，它将技术架构归入实现细节，并用领域对其进行封装。以技术为中心的组织单元中员工与员工之间彼此隔离，要想在这样的组织中构建以领域为中心的架构是很难的。
许多技术人员在构建数字化企业中遇到的的重要问题之一是为了支持如移动应用等新举措却被那些需要拆分的遗留系统所拖累。如今，这些企业越来越多地使用微服务作为这种拆分过程的关键战略。
Greenfield项目得益于DDD实践。通过DDD理解了他们的问题领域以及重要组件之间的接口所在。对于现有项目，更加模块化的系统会促使开发者解开事务性的泥球，并且可以在那些属于一起的组件和偶然耦合的组件之间做更清楚地区分。
团队
你还将遇到微服务对团队影响：一个架构风格是如何推动开发团队的重组。
1968年，梅尔文·康威对软件开发做了一个很有预见性的观察，被称为康威定律：
设计系统的组织…其产生的设计等价于这些组织间的沟通结构。
康威定律对软件开发的意义是什么呢？你的设计反映了你的团队结构。企业常见的团队结构是由人力资源部门推动的，他们将类似的技术专家组织在一起。虽然这是一种符合逻辑的排序算法，但这种结构在设计自包含服务时效果不佳。
如我们认为的康威逆定律，现在许多公司在围绕业务领域组织跨职能团队，而不是围绕技术分层构建。例如，一个Customer服务可能包括一个业务分析师，开发人员，QA，UX，DBA和运维人员，
团队会在准备好之后部署服务，而不是构建一些东西传递到运维人员以包含在下一个巨大的发布中。许多选择微服务的公司使用持续部署，以尽快将变更投入生产环境中。
总结
企业高管可能会认为微服务是最新流行词而不予考虑，但那些了解这种架构影响的人可以获得实实在在的好处。微服务可以提高交付速度，增强灵活性，并提高效率。他们将工作进行重组，并与业务问题域保持一致，而不是技术域；从一组独立，更易于开发和维护的服务中创建业务应用程序；更好地匹配技术解决方案与业务问题的复杂程度；构建可以帮助重组现有遗留系统以及创建能够快速响应不断变化的业务条件的新产品和服务的自适应架构。
威廉·吉布森是正确的—许多公司已经将IT竞争力看作鲁棒性一个新的度量。对于这些企业来说，未来已经在这里了。其他还没有意识到这一点的公司可能会发现他们的未来已经收到了影响。
原文链接：https://www.thoughtworks.com/cn/insights/blog/cxo-guide-microservices