英语原文共 33 页，剩余内容已隐藏，支付完成后下载完整资料
第三章
微服务系统的设计
到目前为止我们已经了解到，以微服务方式构建应用程序的公司不仅仅是实现小的组件。我们现在知道，对于什么构成微服务体系结构来说，没有一个严格的定义。相反，重点在于通过可替换性来构建按比例平衡系统运行速度和安全性的应用程序。在本书的其余章节中，我们将深入探讨采用微服务架构的细节。但是，考虑到迄今为止您对微服务系统的了解，有一点要清楚的是有很多活动环节需要考虑在内。微服务体系结构的标志可能是较小的服务，但这些服务遵循微服务的方式值得我们更全面的思考。您需要调整您的文化、组织、体系结构、接口和服务，以正确的方式平衡系统运行速度和安全的比例。
在本章中，我们将在某种程度上为您的应用程序思维方式打好基础，以帮助您发掘微服务系统的潜在价值。我们引入的概念来源于一些相当大的领域：设计、复杂性和系统思维。但要成为一个好的微服务设计师，您并不需要成为这些领域的专家。相反，我们将强调一种模型驱动的应用程序思维方式，它封装了复杂性和系统思维的根本部分。最后，在这一章的结尾，我们将介绍一个设计过程的例子，它可以帮助推动一种设计驱动的方法来实现微服务。
基于微服务的系统
我们发现许多首次采用微服务的人往往将注意力集中在需要构建的服务上。但是为了以微服务的方式开发应用程序，您需要将设计概念化，而不是孤立的、单独的服务设计。这并不意味着服务的设计可以被忽略——就像汽车和行人对交通系统是必不可少的一样，服务是微服务系统的关键组成部分。但是仅仅从服务的角度考虑是不够的，相反，您需要考虑系统的各个方面如何协同工作以形成突现行为。突现行为是指大于其各部分之和的行为，对于微服务应用程序来说，这包括当我们将各个服务连接在一起时出现的运行时行为，以及使我们到达该位置的组织行为。
涌现是复杂性科学的重要组成部分，是系统复杂性的重要指标。复杂性科学家梅拉妮·米歇尔（以在圣菲研究所工作而闻名）经常用蚁群来阐述涌现和复杂性：预测一只蚂蚁的行为是微不足道的，但预测整个蚁群的行为要困难得多。
一个微服务系统涵盖了与您的组织有关的所有事物，这些事物与它所产生的应用程序有关。这意味着您的组织结构、在那里工作的人、他们的工作方式以及他们生产出的产品都是重要的系统因素。同样重要的是运行时体系结构元素，如服务协调、错误处理和操作实践。除了您需要考虑的广泛主题之外，还有一个额外的挑战，即所有这些元素都是相互关联的—系统某个部分的更改可能会对另一部分产生不可预见的影响。例如，更改实施团队的规模可能会对实施团队的工作产生深远的影响。
如果您在正确的时间执行正确的决策，则可以影响系统的行为并产生所需要的行为。但这往往说起来容易做起来难。同时处理所有这些系统元素是困难的。事实上，您可能会发现在脑海中对微服务系统的所有活动部分进行概念化尤其具有挑战性。我们从中了解到了，微服务系统是复杂的！
复杂性科学家在处理复杂系统时也面临类似的挑战。由于所有相互关联的部分以及由此产生的复杂现象，很难理解这些部分是如何协同工作的。特别是，很难预测系统变化可能产生的结果。所以，他们做了科学家们一直做的事情——他们开发了一个模型。
数学家为研究复杂系统而开发的模型使他们能够更准确地理解和预测系统的行为。但这是一个尚处于起步阶段的领域，他们建立的模型往往非常复杂。我们不期望您理解复杂性的数学，也不认为它对创建更好的微服务应用程序特别有帮助。但我们相信，基于模型的方法可以帮助我们所有人概念化我们的学习体系，并使我们更容易讨论体系的各个部分。
有鉴于此，图3-1描述了一个由五部分组成的微服务设计模型：服务、解决方案、过程和工具、组织、文化。
图3-1 微服务系统设计模型
事实上，这些设计元素中的每一个都值得一读，我们在附录A的阅读列表中为您指出了一些重要的来源。但是这个模型的目标是突出关注的主要领域以及您需要影响的系统部分，以便成功地使用这种体系结构样式。
服务
实现设计良好的微服务和API是微服务系统的关键。在微服务系统中，服务形成了原子构件，整个有机体就是由这些原子构件搭建起来的。如果您能够正确地确定服务的设计、范围和粒度，您将能够从一组看似简单的组件中归纳出复杂的行为。
在第5章中，我们将为您提供一些设计有效的微服务和API的指导。
解决方案
解决方案体系结构不同于单个服务设计元素，因为它代表了解决方案的宏观视图。当设计一个特定的微服务时，您的决策受限于产生单个输出的需求，而这个输出就是服务本身。相反，在设计解决方案体系结构时，您的决策受限于协调多个服务的所有输入和输出的需求。该系统的宏观视图使设计人员可以得出更理想的系统行为。例如，提供发现、安全和路由功能的解决方案体系结构可以降低单个服务的复杂性。
在第6章中，我们将深入探讨可以用来产生良好的微服务系统行为的模式。
过程和工具
您的微服务系统不仅仅是在运行时处理消息的服务组件的副产品。系统行为也是系统中的工作人员用来完成工作的过程和工具的结果。在微服务系统中，这通常包括与软件开发、代码部署、维护和产品管理相关的工具和过程。
选择正确的过程和工具是产生良好的微服务系统行为的一个重要因素。例如，采用标准化流程（如DevOps和Agile）或工具（如Docker容器）可以提高系统的可变性。在第4章和第6章中，我们将更深入地了解对微服务系统影响最大的流程和工具。
组织
我们的工作方式往往取决于我们的同事和沟通方式。从微服务系统的角度来看，组织设计包括结构，权限方向，粒度和团队组成。许多在微服务架构方面取得成功的公司都将组织设计作为一个关键要素。但是组织设计是非常具有上下相关性的，如果您在一个10个人创业的公司之后尝试建立500多名员工的企业结构模型（反之亦然），您可能会发现自己处于一个糟糕的境地。
优秀的微服务系统设计人员了解更改这些组织属性的含义，并且知道良好的服务设计是良好的组织设计的副产品。我们将在第4章深入探讨团队设计概念。
文化
在所有的微服务系统领域中，文化也许是最无形的，但也可能是最重要的。我们可以广义地将文化定义为组织内所有员工共享的一组价值观、信仰或理想。组织的文化很重要，因为它塑造了系统内人员将做出的所有最根本的决策。如此大的影响力使它成为系统设计工作中的一个非常强大的工具。
与组织设计非常相似，文化是系统的上下文敏感相关功能。它可能在日本有效，在美国行不通；可能在大型保险公司有效，在电子商务公司行不通。因此，当您尝试仿效一家您欣赏其文化的公司的有效做法时，您需要格外小心谨慎。没有任何配方或行动手册能保证您得到同样的结果。
一个组织的文化固然重要，但却难以衡量。正式的测量和建模方法已经存在，但是许多业务和技术领导者以更本能的方式评估他们团队的文化。您可以通过与团队成员、团队产品以及他们所服务的客户的日常互动来了解组织的文化。
不管您如何衡量它，文化往往是您的系统其他部分的影响指标。共同的理想塑造了人们的工作方式，他们的工作方式反过来也会塑造他们的组织观。这就是系统相互关联的本质。
适应变化
时间是微服务系统的一个基本要素，如果不考虑它会是一个严重的错误。您对组织、文化、流程、服务和解决方案所做的所有决定都应该植根于这样一个观念：变革是不可避免的。您不能在系统设计中完全确定；相反，您应该将适应性作为一种特性设计到系统中。
采取这种观点有很好的理由：首先，试图确定组织和解决方案设计的最终状态几乎是不可能完成的任务。其次，做出设计决策的环境不太可能保持不变。需求、市场和技术的变化都会使今天的好决策很快过时。
优秀的微服务设计人员了解适应性的需求，并努力不断改进系统，而不是简单地制定解决方案。在本书的第三部分中，我们将为您提供一些用于提高系统适应性的实用模式和工具。
整合：整体系统
当把所有这些设计元素放在一起时，就形成了微服务系统。它们是相互关联的，对一个元素的更改可能会对其他元素产生有意义的、有时是不可预测的影响。系统会随着时间的推移而变化，而且不可预测。它产生的行为大于其单个组件的行为。它适应不断变化的背景、环境和刺激。
简言之，微服务系统是复杂的，要想从该系统中获得令人满意的行为和结果并不是一件容易的事。但有些组织在这方面取得了巨大成功，我们可以从他们的例子中学习。
标准化与协调
准确地说，我们不能说领导能让组织取得最高绩效，因为没有人能让它发生。领导只能识别和修改阻止它的条件。
——迪霍克，《领导艺术》一书的作者
几乎我们所有人都在有限制的组织中工作。之所以会出现这些限制，是因为错误的系统行为类型可能对组织有害，甚至会由于行为特别糟糕而导致组织失败。例如，一个银行技术系统可以很容易地窃取别人的钱，或者一个税收系统不能保护用户的私人信息，都是难以接受的。
由于不必要的系统行为造成的损失如此之高，因此，如此多的架构师和设计师竭尽所能来控制系统行为也就不足为奇了。在实践中，系统设计者决定有一些行为或期望必须普遍应用于系统中的参与者。引入策略、治理和审计都是为了管理系统的行为并确保参与者遵守规则。换句话说，系统的某些部分是标准化的。
但对这种复杂系统的真正控制是一种幻想。您有很大的把握保证您的银行系统将是完全安善的，就像一个农民保证他的庄稼将永远生长一样。无论您采用多少规则，检查和治理方法，您始终会受制于可能做出错误决策的系统中的参与者。
相反，所有这些控制机制都会对系统产生影响，从而大大增加获得所需结果的可能性。掌握您正在设计的系统并使其实现您想要的功能需要您制定正确的标准，确保标准得到应用，并衡量您所做更改后的结果。
然而，对系统的控制要付出高昂的代价。标准化是适应性的敌人，如果您标准化了系统中太多的部分，您就有可能创造出代价高昂、难以改变的东西。
组织设计师亨利明茨伯格（Henry Mintzberg）在他的《五字形结构》一书中指出了一些协调机制和标准，这些机制和标准对组织系统的影响最大。他特别指出，工作产品、工人技能和工作流程的标准化影响最大。
不要被我们使用的“标准化”这个词吓跑了！当我们谈论标准时，我们指的是组织内部存在的既定规范和公认的工作方式。本节的目的是了解标准化集中于公司不同部门时对系统的影响。
标准化过程
我们已经讨论了流程和工具对于系统中出现的行为的重要性。通过标准化人们的工作方式和他们使用的工具，您可以以一种更可预测的方式影响人们的行为。例如，随着新部署成本的降低，标准化部署过程减少了组件部署时间，可能会提高系统的整体可变性。
标准化我们的工作方式对我们可以生产的工作类型，雇用的人员类型以及组织的文化具有广泛的影响。敏捷方法是过程标准化的一个很好的例子。“敏捷”制度化了应该以较小的可测量增量引入变更的概念，从而使组织能够更轻松地应对变更。对于敏捷团队来说，一个可以观察到的系统影响使得他们产生的输出开始改变。软件版本变得更小，可测量性成为他们输出产品的一个特征。他们的文化和组织设计通常也有后续效应。
除了过程标准化，大多数公司还采用某种形式的工具标准化。事实上，许多大型组织的部门的唯一目的是定义允许其员工使用的工具类型。例如，一些公司禁止使用开源软件，并限制他们的团队使用由专业团队采购的中央批准的软件。
微服务工具领域的发展非常迅速，我们可以确定，到本书出版时，任何关于特定微服务工具的讨论都将过时。但我们在第4章中努力描述了对标准化特别重要的工具类型，以及一些目前特别相关的工具示例。
标准化输出
我们可以将团队定义为一组员工，他们接受一组输入并将其转换为一个或多个输出。输出标准化是为输出的外观设置一个通用标准的方法。例如，在装配线上，生产线工人的产量是标准化的，生产线上的每个人必须产生完全相同的结果。任何偏离标准输出的情况都被视为失败。
在微服务系统中，一个团队接受一组需求并将其转化为微服务。因此，服务就是输出，输出的面就是接口（或API），它提供了对微服务提供特性和数据的访问。事实上，从微服务消费者的角度来看，API就是输出，因为它们对其背后的实现没有可见性。
在微服务环境中，输出标准化通常意味着为公开服务的API制定一些标准。例如，您可以决定组织的所有服务都应该具有HTTP接口，或者所有服务都应该能够订阅和发送事件。一些组织甚至将界面的设计标准化，以提高使用服务的可用性、可变性和整体体验。在第5章中，我们将深入探讨对微服务系统有意义的API标准化类型，以及不同类型接口样式的好处和成本。
规范人员
您还可以标准化在您的组织中执行工作的人员类型。例如，您可以为希望在微服务团队工作的任何人引入最低技能要求。事实上，许多分享微服务故事的公司都将员工的技能水平作为其成功的主要特征。
将技能或才能标准化是将更多自主权引入微服务系统的有效方法。当实现服务的人员技术更熟练时，他们就有更好的机会做出决策，从而创建您想要的系统行为。
所有的组织都有一定程度的最低技能和经验水平的员工，但优先考虑技能标准化的组织往往设置非常高的专家要求，以获得系统收益。如果只有最优秀和最聪明的人才能够在您的系统中工作，那么就要准备好付出高昂的代价来维持这个标准。
标准化权衡
标准化可以帮助您对系统产生影响，但您不必只选择其中一个标准来使用。但请记住，虽然它们不是相互排斥的，但引入不同的标准化模式，可能会在系统的其他部分产生意想不到的后果。
例如，您可能决定对所有微服务公开的api进行标准化，因为您希望降低在解决方案体系结构中将
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[405559]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
