1.未来已经来临，只是分布不均。-WilliamGibson数字时代就在我们身边。将软件开发视为昂贵费用而非竞争优势的企业将会陷入困境。要参与这个数字世界并在其中蓬勃发展，企业必须学会适应我们时代的不确定性——更快地将新产品推向市场，快速高效地改进现有产品，并为客户体验提供有意义的数字。为实现这些目标，企业需要将敏捷性/适应性整合到三个领域：人员、流程和技术。人们需要适应实验和变化。在“迭代”中推进过程并加强学习。技术，包括技术架构，需要支持产品和服务的快速交付。技术敏捷性不容忽视——敏捷的团队和流程无法弥补笨拙的技术。但是，作为一名高级管理人员，您应该将注意力集中在新技术世界中的什么地方？这个问题的答案被不懈地讨论看似神秘的话题的技术人员所掩盖。管理层需要注意哪些神秘话题？最重要的主题之一是微服务。原因如下：微服务影响人、流程和技术：包括团队组织结构、流程和实践（如DevOps），重新调整架构以适应我们要解决的问题，而不是单纯的技术层面。微服务促进了每个领域的适应性。值得管理层花时间了解其潜在贡献。技术敏捷性微服务架构风格的特点是一组极小的服务，它们彼此独立，单独部署。微服务受到Netflix等公司的欢迎。每个服务都包含一个离散的业务功能，它在技术上与其他服务隔离，从而产生类似乐高的效果：开发人员可以在不破坏其他服务的情况下将服务切换到新服务。就像可以用75,000块乐高积木拼成一个巨大的乐高模型一样，可以使用这些受乐高启发的服务来构建大型数字应用程序。这种架构有一些明显的好处。首先，每个服务都与其他服务高度分离，这意味着它们是独立的。因此，一项服务的技术变更（如数据结构变更）不会影响另一项服务。服务仍然可以通过消息传递进行通信，但不允许任何服务修改对方的实现细节。其次，由于开发人员不需要共享基础设施，他们可以使用适合问题复杂性的技术栈来实现每项服务。鉴于当今技术堆栈的复杂性，在同一应用程序中使用简单工具解决简单问题并使用复杂工具解决复杂问题的能力允许开发团队提高灵活性，同时降低成本。***看重能把复杂问题简单化的技术专家。第三，每个服务都封装了业务功能，这使得围绕特定问题领域培养团队比按工作功能划分团队更容易。例如，服务团队通常包括开发人员、业务分析师、DBA、操作员和QA——构建和部署服务所需的一切。这降低了协调成本。“从职能型组织结构向产品或服务型结构转变”是企业敏捷转型的增长趋势。微服务架构支持这种趋势变化。***，由于各个服务相互隔离，服务组成的架构快速灵活。同时，由于服务的业务范围小，服务的变化可以很快发生，为开发者提供了新的高级功能。一旦架构师设计了一个小型独立服务系统，其中应用程序由多个已部署服务之间的消息传递组成，诸如多变量测试之类的事情就变得容易了。（图片来自：https://dt-cdn.net/）例如，企业可能不确定其网站未来的发展方向。因此，他们设计了两个相似但功能不同的服务，并为不同的用户群部署不同的版本，以获得能够推动未来发展的结果。像Facebook这样的公司也在试验这种类型的A/B测试来分析他们的用户。标准化一直是IT组织降低成本的方法之一。不幸的是，它也降低了灵活性——标准化越多，灵活性就越差。通过采用微服务架构，架构师和开发人员可以使用更加多样化的技术堆栈来设计应用程序，这些技术堆栈能够密切反映问题的复杂性。微服务架构风格与许多企业部署软件和分配IT资源的方式相反。许多架构风格的主要目标之一是有效地利用共享资源（操作系统、数据库服务器、应用程序服务器等）。因为资源成本影响底线，所以这些公司构建软件架构以最大化共享资源。但是，共享资源有一个缺点。无论开发人员如何有效地建立与这些服务器的隔离，都将存在对这些资源的竞争。有时由于依赖管理导致组件相互干扰，有时由于两个组件竞争某些资源（例如CPU）而出现问题。这不可避免地导致共享组件以意想不到的方式进行交互。容器与解耦在软件交付中，有两个关键的技术“环境”：开发人员工作的开发环境，以及IT运维人员在职权范围内的部署环境。传统上，在这两个环境之间移动代码充满了技术错误、长时间延迟和组织层面的沟通不畅。几年前，发生了一件有趣的事情：Linux对大多数企业来说足够友好，而且Linux的变体在商业上是免费的——但不足以影响技术架构。接下来，开源创新与敏捷开发技术的结合鼓励开发人员创建各种工具来自动化许多繁琐的运维手动操作。这被许多人称为DevOps革命。通过使用Puppet、Chef和Docker等高级工具，这场革命使开发团队和IT运营更加紧密地联系在一起。出乎意料的是，Linux的变体允许自由运行，开发人员可以将他们的组件部署到本地操作系统而不受干扰。一整类可能的错误突然消失了，因为组件可以相互解耦。如果开发人员可以构建自己的真实环境，他们就可以减少与运营部门的协调，从而减少组织间的摩擦。以编程方式启动类似生产环境的能力消除了共享环境中的测试、集成、资源争用以及许多其他问题。面向21世纪的架构敏捷性在治理方面，微服务架构风格还有其他好处。传统上，企业架构师定义组织的共享技术堆栈，以最大限度地利用跨项目的资源，同时最大限度地降低支持成本。例如，一家大型企业可能将Java和Oracle标准化为其主要开发平台。如果每个人都使用Oracle，企业中的一切都可以存储在一个工业级数据库中。规范治理有一个缺点——通常，团队必须使用不太理想的工具来实现某种标准化目的。与此同时，还有一个潜在的更微妙的缺点。例如，考虑一个大型企业选择了对特定消息队列进行标准化。在评估需要这种共享基础架构的所有项目时，企业架构师会识别最复杂的场景，并选择适合该复杂程度的工具来处理它们。然而，许多项目并没有这种最复杂的场景。但是因为每个项目都必须共享相同的基础架构，所以每个团队都必须承担其他团队的大部分复杂性。这也发生在数据库层。许多项目只需要简单的数据存储，只需要几条记录，没有复杂的查询功能，最终会使用工业级数据库服务器，因为这是企业的常态。容器化通过摆脱共享基础设施来解决这个问题——每个项目都部署在自己的本地容器化环境中。因为没有共享驱动器来选择工具，所以每个项目都会特意选择最适合自己的工具。当然，如果企业架构师允许每个项目选择自己的技术堆栈，就会有一些严重的缺点。我们经常看到一种叫做“GoldilocksGovernance”的做法（企业架构师选择几个技术栈——简单、中等和复杂，并根据规模分配新项目），适用于高度解耦的环境。这些知识是可以转移的，公司仍然可以从中受益，但可以避免无意中使问题过于复杂化。我们为什么在这里？EricEvans的书《领域驱动设计》对微服务架构的发展产生了巨大的影响。它引入了一种将大问题空间分解为领域或重要实体（例如客户和订单）及其关系（客户下订单）和行为的技术。域定义的一部分是有界上下文的概念：每个域围绕实现细节形成一个封装层。例如，如果分析师识别出一个客户域，它就存在于自己的限界上下文中。在Customer上下文中，开发人员知道所有的实现细节：类结构、数据库模式等。但是，其他有界上下文（例如Orders）看不到这些实现细节。虽然领域可以出于协调目的相互发送消息，但两个领域都不能穿透另一个领域的有界上下文。因此，一个有界上下文中的开发人员可以自由更改实现，而不必担心破坏其他领域。微服务中的容器是领域驱动设计（DDD）中限界上下文的物理表示：每个容器代表一层封装，以防止实现细节干扰系统的其他部分。限界上下文提供的隔离展示了构建软件架构的不同方式。过去，设计架构主要围绕技术架构：架构模式、库、框架等。例如，分层架构在许多组织中很常见：图1：传统分层架构在图1中，架构师沿技术层分离，使得在需要时很容易替换一整层内容。例如，如果一个开发者需要改变持久化机制，所有相关的代码都会出现在持久化层。那么开发人员多久更换一次整个持久层呢？几乎从不。但是，您的团队处理客户等概念的频率如何？每天！在图1的分层架构中，客户在哪里？其中一些位于表示层、业务层、持久层等。因此，项目架构的公共单元的更改在分层架构中得不到很好的支持，因为公共更改会影响每一层。如果不同层代表开发团队的不同部分，则影响会更加严重。例如，对Customer的更改可能涉及用户界面、业务逻辑、持久层和其他功能。如果您的组织由独立人力资源部门下的开发人员、DBA、UI设计人员和运营人员组成，那么进行共同更改的协调成本是巨大的。微服务强调解耦和容器化，翻转图1中的传统方式，将领域作为架构的主要元素，如图2所示。图2：Domain-CentricArchitecture在图2中，分层结构仍然存在，但其耦合boundary是领域的边界，将技术架构作为实现细节纳入其中，并与领域一起封装。在员工彼此隔离的以技术为中心的组织单元中，很难构建以领域为中心的架构。许多技术人员在构建数字企业时遇到了问题：试图支持移动应用程序等新举措，但被需要拆除的遗留系统所阻碍。如今，这些企业越来越多地引入微服务作为这种分拆过程的关键策略。Greenfield项目受益于DDD实践。通过DDD了解他们的问题域和重要组件之间的接口。对于现有项目，一个更加模块化的系统迫使开发人员理清交易泥团，并更清楚地区分那些属于一起的组件和那些偶然耦合的组件。团队您还将遇到微服务对团队的影响：架构风格如何推动开发团队重组。1968年，梅尔文·康威(MelvinConway)对软件开发做出了先见之明的观察，称为康威定律：设计系统的组织产生的设计等同于这些组织之间的通信结构。康威定律对软件开发意味着什么？您的设计反映了您的团队结构。企业中常见的团队结构是由人力资源部门驱动的，他们将具有类似职能的技术专家聚集在一起。虽然这是一种逻辑排序算法，但这种结构在设计独立服务时效果不佳。正如我们想到的康威逆定律，许多公司现在围绕业务领域组织跨职能团队，而不是围绕技术层构建。例如，客户服务可能包括业务分析师、开发人员、QA、UX、DBA和运营人员。团队在准备就绪时部署服务，而不是构建一些东西并将其交给Ops以包含在下一个大版本中。许多选择微服务的公司使用持续部署来尽快将变更投入生产。总结业务主管可能会将“微服务”视为一个流行词而不屑一顾，但那些理解这种架构含义的人可以获得切实的好处。微服务可以提高交付速度、增强敏捷性并提高效率。他们重组他们的工作并使其与业务问题领域而不是技术领域保持一致；从一组独立的、更易于开发和维护的服务中创建业务应用程序；更好地匹配业务问题的技术解决方案的复杂性；构建可帮助重组现有遗留系统的自适应架构，以及创建可快速响应不断变化的业务条件的新产品和服务。WilliamGibson是正确的——许多公司都将IT竞争力视为一种新的稳健性衡量标准。对于这些企业来说，未来已经来临。其他没有意识到这一点的公司可能会发现他们的未来已经受到影响。【本文为专栏作家《ThoughtWorks》原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
