微服务
微服务是一种架构，其中的大型、复杂的软件应用程序由一个或多个更小的服务组成。每个微服务仅负责完成一项代表一种小业务能力的任务。这些微服务可使用任何编程语言开发。
本系列内容针对 Delphi 的微服务最佳实践展开讲解。
微服务架构
微服务是相对较小的自主服务，它们合作完成工作。每个服务都实现一种业务需求。
微服务架构是 Martin Fowler 和 James Lewis 定义的一种架构风格。他们将这种风格描述为”一种使用小型服务构建系统的架构方法，每个服务都在自己的进程中，它们通过轻量型协议进行通信”。有关的更多信息，请参阅 Martin Fowler 编写的”微服务：一个新的架构术语“。
每个服务都是相互独立开发和部署的。每个微服务都专注执行一个它所擅长的相对较小的任务。
小型且专注于业务领域
小 并不能充分描述微服务，使用这个词只是为了尝试表明微服务相对于整体式应用程序的大小。在此上下文中，小的定义可能在各个系统中各不相同，而且没有规则来定义服务必须有多小。
微服务通常负责一个精细的工作单元，所以它在规模上相对较小。一条著名的指导原则是”两块披萨的团队规模”方案，意思是说， 如果两块披萨不能将整个团队喂饱，那么这个开发微服务的团队可能太大了。 微服务必须足够小，使得团队中的每个人都能理解该服务的整体设计和实现。另外，它的大小必须足以让团队在必要时轻松地维护或重写服务。
微服务的另一个重要特征是，每个服务专注负责一项精细的业务。Vaughn Vernon 在他撰写的图书 《实现领域驱动设计》 中定义了术语 业务领域 。他将业务领域定义为，”某个组织执行的操作和它执行操作的环境。”他还指定，”每个组织都有自己独特的知识范围和操作方式。这个理解范围和它执行操作的方法就是它的领域。”被分解为微服务的单元实际上就是领域内的业务实体，这意味着每个微服务处理完成一个完整的业务任务。例如：Mortgage Services 是一个业务领域。Loan Origination 是该领域中一个可能的微服务。Loan Refinancing 可能是同一个领域中的另一个微服务。跨服务边界的调用和更改通常很耗资源，必须避免。拥有这些服务的团队成为相应业务领域或子领域的专家，而不是任意技术领域的专家。
与技术中立
开发微服务的团队必须使用他们熟悉的技术。不要规定开发团队应该使用何种编程语言。让开发人员自由选择对任务最有意义的技术和执行任务的人。这种工作方式能够充分利用团队成员拥有的最佳技术和技能。微服务架构仍需要技术决策；举例而言，使用具象状态传输 (REST) 应用编程接口 (API) 访问更好一些，还是使用某种类型的排队来访问更好一些？但是，一般而言，您可以为微服务架构选择广泛范围内的任何技术。
松散耦合
松散耦合对基于微服务的系统至关重要。每个微服务都必须采用使其与其他服务的关联很小的方式来设计接口。这样，在更改一个服务并部署它时，就无需更改和重新部署系统的其他部分。
为了避免服务之间的耦合，必须了解导致紧密耦合的原因。紧密耦合的一个原因是通过 API 公开服务的内部实现。这种公开方式将服务的使用者与它的内部实现绑定在一起，从而导致更高的耦合度。在这种情况下，如果更改微服务的内部架构，可能还需要更改服务的使用者，否则就会破坏使用者。这可能会增加更改的成本，给实现更改带来潜在隐患，进而增加服务中的技术债务。必须避免任何导致公开服务的内部实现的方法，以确保微服务之间松散耦合。
另一个错误是让服务的 API 太过精细。如果 API 太过精细，服务之间的调用可能变得太过 频繁 ，也就是说，会通过网络执行更多的调用。除了前缀的性能问题，过度频繁的通信还可能造成紧密耦合。因此，设计服务接口的方式必须能够最大限度地减少网络中执行的来回调用。
必须避免一个服务内的实现过于分散，方法是将表示业务实体的相关属性、行为放在尽可能相近的地方。将相关属性放在一个微服务中；如果更改某个属性或行为，可以在一个位置更改它并快速部署该更改。否则，必须在不同部分中执行更改，然后同时一起部署这些散乱的部分；这会导致这些部门之间紧密耦合。
每个微服务必须有自己的源代码管理存储，以及用于构建和部署的交付管道。这样即可在必要时部署每个服务，而不需要与其他服务的所有者进行协调。如果您有两个服务，而且始终在一次部署中一起发布这两个服务，这可能表明两个服务最好合并为一个服务，而且必须对当前服务执行更多分解工作。松散耦合还支持更频繁、更快速的部署，最终提高应用程序对其用户需求的响应能力。
容易观察
微服务架构要求您能够 可视化 系统中所有服务的健康状态，以及它们之间的连接。这使您能快速找到并响应可能发生的问题。实现可视化的工具包含一种全面的日志机制，能够记录日志，存储日志，并使日志容易搜索，以便执行更有效的分析。
向系统中配置和添加的新服务越多，让这些服务变得可观察就会越难。因为在添加更多动态部分时，微服务架构会增加复杂性，所以观察设计必须明确，使可视化的日志和监视数据能为分析提供有帮助的信息。
自动化
自动化是有效设计和实现软件应用程序的一个重要要求。对于微服务，自动化是一个至关重要但又充满挑战的任务。除了需要在生产中运行系统之外，微服务架构还向系统的实现引入了更多复杂性。在处理的机器和组件数量较少时，可能可以接受手动配置机器，安装中间件，部署组件，或者手动登录到服务器并收集日志，以及执行其他手动任务。但是，当组件数量增加时，在某个时刻后，您可能无法使用手动方法。
自动化可帮助组建一个服务器并安装必要的运行时环境。然后，只需使用几行代码，就能快速将微服务放在这些运行时环境上。这种自动化使您能编写微结构代码，访问用于部署生产服务的准确的工具链，从而及早发现问题。自动化是连续集成和连续交付方法的核心推动力量。如果您想将微服务架构的复杂性保持在控制范围内，推崇自动化文化是关键。为此，您需要一种综合的、端到端的方法，以便在整个软件开发生命周期中推广自动化。这个生命周期涉及通过一些操作执行测试驱动开发。
现在单体式应用程序面临的挑战
在 整体式应用程序 中，大部分逻辑都部署在一个集中化、单一的运行时环境或服务器中，并在其中运行。整体式应用程序通常很大，由一个大型团队或多个团队构建。采用此方法，各个团队需要花更多精力和统筹安排才能执行更改或部署。
随着时间的推移，整体式模型中已引入了更好的架构模式，有助于显著提高架构的灵活性。例如，一种著名的模式是模型-视图-控制器 (MVC)，它将应用程序分解为层和合理的组件。这些模式有多种优点，比如更快的初始开发、更简单的应用程序治理，等等。但是，整体式模型也有缺点，尤其是在当今环境中的技术瞬息万变的背景下。
整体式方法可能带来许多挑战，有以下四点：
-
庞大的应用程序代码库
庞大的代码库可能给希望熟悉代码的开发人员带来困扰，尤其是团队的新成员。庞大的应用程序代码库可能还会让应用程序开发过程中使用的开发环境工具和运行时容器不堪重负。最终，这会导致开发人员效率降低，可能会阻止对执行更改的尝试。
-
不频繁的更新
在典型的整体式应用程序中，大部分（几乎是全部）逻辑组件都部署在单一运行时容器中，并在其中运行。这意味着要更新对某个组件的一处细微更改，必须重新部署整个应用程序。另外，如果需要推广细微但关键的应用程序更改，则需要投入大量精力来对未更改的部分运行回归测试。这些挑战意味着整体式应用程序很难连续交付，这导致部署次数减少，对需要的更改的响应变慢。
-
依赖单一类型的技术
对于整体式模型，由于应用更改方面的挑战，以增量方式采用新技术或技术栈开发框架的新版本会变得很困难。最终，整体式架构应用程序通常必须一直使用这一种技术，这最终会阻碍应用程序跟上新的发展趋势。
-
可扩展性
可扩展性是整体式架构面临的最大挑战之一。Martin Abbot 和 Michael Fisher 在他们合著图书 《可扩展的艺术》 中介绍了一种查看系统的可扩展性的有用方式；他们使用了一种三维可扩展性模型或扩展立方体。在此模型中，通过在负载平衡器后运行克隆版本来扩展应用程序称为 X 轴扩展或水平复制。另外两种扩展是 Y 轴扩展（或功能分解）和 Z 轴扩展（或数据分割），Y 轴扩展通过拆分不同实体来实现扩展，Z 轴扩展通过拆分类似实体来实现扩展。由于整体上的凝聚性，典型的整体式应用程序通常只能在扩展立方体的一个维度上扩展。随着生产环境收到更多请求，该应用程序通常采用的垂直扩展方式是添加更多资源供其使用，或者克隆到多个副本来进行响应。这种扩展方式低效且很耗资源。
当应用程序达到一定规模时，开发团队必须拆分为更小的团队，每个小团队专注于一个特定的功能区域，各团队彼此独立工作，而且通常位于不同地理位置。但是，由于应用程序的各部分间的自然凝聚性，需要各个团队协力执行更改和重新部署。
使用微服务架构的最重要目的是，解决整体式模型面临的难题。
对于业务所有者
作为业务所有者，您希望您的服务适用于新客户和业务需求。但是，在整体式模型中，由于庞大的代码库，为满足业务需求而执行并推广更改的过程会很缓慢。这个过程缓慢的另一个原因是，各个组件和层之间有严格的内部限制和依赖关系。
微服务架构原则是围绕高灵活性和恢复能力而建立的。这两个特征有助于快速推广更改。这有助于业务所有者更快地收到反馈，调整业务和投资战略，从而让客户满意和提高市场竞争力。
从资源分配的角度讲，由于团队更小且更专注，所以可以更轻松地测量和可视化效率。然后，业务所有者可以更轻松地制定投资决策，可将资源从低业务影响区域转移到高业务影响区域。
对于服务管理人员
作为服务管理团队成员，您希望协调各个团队的管理操作负担更少，以便您可以提高服务的生产力。整体式模型需要做大量的工作。活动之间需要的协调更多，因为整体式应用程序通常拥有庞大的业务范围，以及许多基础架构和操作接触点。因此，对应用程序的每次更改都可能需要不同涉众多次评审和批准。微服务架构推崇利用自助服务，在服务交付管道的每个阶段利用自动化。
这有助于减少服务管理团队的日常管理协调。
微服务架构中的一个重要原则是高可观察性。高可观察性功能为服务管理团队提供了必要的工具，以便更好地监督系统中或产品中的每个微服务的状态。这有助于提高服务管理效率。
对于开发人员
作为加入团队的新开发人员，您希望快速熟悉源代码，以便快速上手并带来成果。典型整体式应用程序中的代码库很大，可能阻碍您并潜在地延长学习曲线。对于所有开发人员，庞大的代码库会增加载入开发环境中并运行的负担，从而导致生产力降低。
庞大的代码库可能让代码评审和其他合作开发活动面临更大压力。此外，在处理更改时，破坏其他功能的风险可能导致开发人员对创新和增强应用程序犹豫不决。然而，微服务更小且更轻量，这可以缩短新开发人员的学习曲线。微服务还可以帮助消除加载和运行的繁重负担，鼓励引入突破性的更改，从而帮助提高生产力和创新水平。
云环境和产品的激增
微服务架构体现了使用连续集成和连续部署的许多优势。该架构也引入了新的复杂性，需要一种在构建应用程序的每个步骤中实施自动化的现代方法。例如，从基础架构和治理的角度讲，首先需要一个能动态地快速为服务组建运行时环境的业务连续性基础架构。该环境可能是一个虚拟机、容器等。另外，还需要一种统筹安排和监视服务的高效方式。当今环境中的云平台可通过其自然的动态性和恢复能力满足此需求。
借助可用于各种服务模型的不同云产品，无论是基础架构即服务 (IaaS) 还是平台即服务 (PaaS)，开发人员都可以通过更多选择转变为微服务战略。借助 IaaS 选项，您可以在几分钟内快速组建一台机器，而且可以将基础架构配置打包到一组脚本中，以便根据需要自动化该流程。如果您不想接触基础架构级别的复杂性，也可采用平台级选项，采用不同的语言和服务的形式来快速打包，然后根据意愿包含和启动微服务。
除了云基础架构可为微服务战略的采用所提供的动态性和恢复能力，拥有全面的工具也是采用微服务战略的关键需求。微服务工具在不断演变和进步。在当今环境中，开发人员有许多选择，他们可以使用一组合适的工具来实施其微服务战略，比如日志工具组合、监视工具组合、服务注册表或容器化技术。这些先进工具可帮助解决微服务架构所引入的挑战，以便更有效地交付、管理和统筹安排服务。
结束语
本文作为 Delphi 和微服务的第一部分，重点介绍了微服务的重要概念、特征以及它为何对现代软件应用程序的开发如此有吸引力的原因。最后，通过一个示例简单的描述了从整体应用程序向微服务的转变。目前为止，相信您已经对微服务有一个初步的了解。