微服务 spring boot 译<三> 微服务架构

Design with the Domain in Mind

几个世纪以来，模型一直被用来简化和理解一个问题。例如，手机上的 GPS 地图是步行或开车时导航城市的绝佳模型。这个模型对驾驶商用飞机的人来讲是彻底无用的，由于他们使用的模型更适合描述路径点、地标和急流。不一样的模型或多或少都有意义，这取决于它们所处的上下文。EricEvans的开创性著做“领域驱动的设计”(Addison-Wesley，2004)帮助咱们为复杂的业务流程构建模型，这些模型也能够在软件中实现。最终，软件中真正的复杂性不是技术，而是模棱两可的、循环的、矛盾的模型，这些模型是业务人员在头脑中快速梳理出来的。给定一些上下文，人类能够理解模型，可是计算机须要更多的帮助；这些模型和上下文必须融入软件中。若是咱们可以实现与实现绑定的这个级别的建模(反之亦然)，那么不管什么时候业务发生变化，咱们均可以更清楚地了解软件中的变化。咱们着手创建这些模型的过程和围绕它的语言须要时间，而且须要快速的反馈循环。

Evans提供的工具之一是识别和显式分离不一样的模型，并确保它们在各自的有限上下文中具备内聚性和无歧义性。

有界上下文是一组域对象，它们实现了一个模型，该模型试图简化和传递业务、代码和组织的一部分。例如，当咱们真正须要灵活性(听起来熟悉吗？)时，咱们在设计系统时努力提升效率。在一个简单的自动部件应用程序中，咱们试图为整个域提供一个统一的“规范模型”，最终获得像Part、Price和Address这样的对象。若是库存应用程序使用了“Part”对象，那么它将引用一种类型的部件，好比“刹车”或“轮”。在汽车质量保证系统中，部件多是指具备序列号和惟一标识符的很是特定的部件，用于跟踪某些质量测试结果等等。咱们努力尝试有效地重用相同的规范模型，可是库存跟踪和质量保证问题是使用部件对象的不一样业务关注点，语义不一样。对于有界上下文，一个部件将被显式建模为PartType，并在该上下文中被理解为表示“Part类型”，而不是部件的特定实例。有了两个独立的有界上下文，这些部件对象能够在它们本身的模型中一致地演化，而不须要以奇怪的方式相互依赖，所以咱们已经达到了必定程度的敏捷性或灵活性。

这种对领域的深入理解须要时间。可能须要几回迭代才能彻底理解业务模型中存在的模糊性，并正确地将它们分离出来，并容许它们独立地进行更改。这至少是建立微服务很困难的一个缘由。分割一块巨石不是一件容易的事，可是不少概念已经被融入其中，你的工做就是识别和雕刻它。对于一个绿地项目，除非你深入理解它，不然你什么也不能作。事实上，咱们听到的全部微服务成功的故事(好比亚马逊和网飞)在成功过渡到微服务以前都是沿着巨石的道路开始的。

Design with Promises in Mind

在具备自主团队和服务的微服务环境中，记住服务提供者和服务消费者之间的关系是很是重要的。做为一个自主的服务团队，您不能将义务放在其余团队和服务上，由于您并不拥有它们；根据定义，它们是自治的。你所能作的就是选择是否接受他们对功能或行为的约定。做为向他人提供服务的人，您所能作的就是向他们约定某种行为。他们能够自由地信任你或不信任你。约定理论是马克·伯吉斯在2004首次提出的一种模式，他在“寻找肯定性”(O‘Reilly，2015)一书中对此进行了阐述，是对自治系统的研究，包括人、计算机和相互提供服务的组织。

就分布式系统而言，约定有助于阐明服务可能提供的内容，并明确哪些能够作，哪些不能作。例如，咱们的团队拥有图书推荐服务，咱们承诺为您可能询问的特定用户提供一套个性化的图书推荐服务。当您调用咱们的服务，而咱们的后端(存储该用户当前的推荐视图的数据库)不可用时，会发生什么状况？咱们能够抛出异常和堆栈跟踪，但这不是一个很好的经验，并可能炸毁系统的其余部分。由于咱们作出了承诺，因此咱们能够尽一切努力来实现它，包括返回一个默认的图书列表，或者每本书的子集。有时，承诺没法兑现，而肯定最佳行动方案应由咱们但愿为咱们的用户提供的预期经验或结果来驱动。这里的关键是咱们的服务有责任努力履行其承诺(返回一些建议)，即便咱们的依赖服务不能保持它们的服务(数据库已关闭)。在努力履行承诺的过程当中，对系统的其余部分和咱们正在努力维护的服务质量是有帮助的。

Distributed Systems Management

说到底，管理一个单一的系统比管理一个分布式系统要容易得多。若是只有一台机器和一个应用程序服务器，而且系统有问题，咱们知道去哪里找。若是您须要进行配置更改，升级到特定的版本，或者保护它，那么它仍然位于一个物理和逻辑位置。管理、调试和更改它更容易。对于某些用例，单一系统可能有效；可是对于须要规模的用例，咱们能够考虑利用微服务。正如咱们前面所讨论的，微服务并非免费的；为了得到灵活性和可伸缩性，必须管理一个复杂的系统。

关于微服务部署的可管理性的一些简单问题：

• 咱们如何启动和中止服务队？

• 咱们如何聚合跨微服务的日志/度量/SLA？

• 咱们如何在弹性环境中发现服务？

• 负载均衡 ？

• 咱们怎么知道集群的健康或者单个服务的健康？

• 在服务倒下的时候，咱们如何重启咱们的服务？

• 咱们如何进行细粒度的API路由？

• 咱们如何确保咱们的服务安全？

• 若是集群忽然崩溃或发生意外行为，咱们如何节流或断开其部分？

• 咱们如何部署一个服务的多个版本并适当地路由到它们？

• 咱们如何在一大群服务中进行配置更改？

• 咱们如何以安全、可审计、可重复的方式对应用程序代码和配置进行更改？

这些都不是容易解决的问题。本书的其他部分将致力于让Java开发人员使用微服务启动和运行，并可以解决列出的一些问题。完整的，完整的清单，如何为前面的问题(和许多其余)解决的在第二版这本书。

Technology Solutions

在本书的其他部分，咱们将向您介绍一些流行的技术组件，以及它们如何帮助解决使用微服务体系结构开发和交付软件的一些问题。如前所述，微型服务不只仅是一个技术问题，创建正确的组织结构和团队以促进微型服务相当重要。从SOAP切换到REST还并不构成微服务体系结构。

对于建立微服务的Java开发团队来讲，第一步是让一些东西在他们的机器上本地工做！本书将向您介绍三种使用微服务的还比较好的Java框架：SpringBoot、DropWizard 和 WildFlySwarn。每一个框架对于不一样的团队、组织和微服务方法都有好处。正如技术的标准同样，有些工具更适合于工做或团队使用它们。这些并非惟一可使用的框架。有一对框架 Vert.x 和 Lagom 对微服务采起了响应式的方法。使用基于事件的模型进行开发的思惟模式有些不一样，须要一个不一样的学习曲线，所以在本书中，咱们将坚持使用一个大多数企业Java开发人员都会感到温馨的模型。
本书的目标是帮助您掌握每一个框架的基础知识。在最后一章中，咱们将深刻探讨一些高级概念，可是对于每一个框架的第一步，咱们将假设一个hello-world微服务应用程序。这本书并非开发微服务的全面参考资料；每一节都会给您留下参考资料的连接，以便根据须要进行更多的探索。咱们将经过建立多个服务迭代hello-world应用程序，并展现一些简单的交互模式。

每一个框架的最后一次迭代将研究诸如分隔和承诺理论之类的概念，以使咱们的服务在面对错误时具备弹性。咱们将深刻研究NetflixOSS堆栈的某些部分，如hystrix，这些部分可使咱们更容易地实现此功能。咱们将讨论这种方法的优缺点，并探讨存在哪些其余选择。

在咱们浏览这些示例时，咱们还将讨论Linux容器为微服务的部署、管理和隔离以及本地开发带来的价值。Docker和Kubernetes为大规模地处理分布式系统带来了丰富的简化，所以咱们将讨论有关容器和微服务的一些良好实践。

在本书的最后一节中，咱们将为您提供一些关于分布式配置、日志记录、度量和持续交互的想法。

Preparing Your Environment

对于这些示例，咱们将使用Java1.8，并使用Maven构建它们。请确保在您的环境中安装了如下条件：

• JDK 1.8

• Maven 3.2+

•  命令行 shell (bash, PowerShell, cmd, Cyg‐win等）

Spring生态系统中有一些很好的工具，您可能但愿在命令行或IDE中使用。大多数示例将坚持使用命令行，以保持IDE的独立性，由于每一个IDE都有本身处理项目的方式。对于SpringBoot，咱们将使用SpringBootCLI1.3.3。

Spring的IDE和工具：

• Eclipse based IDE: Spring Tool Suite

• Spring Initializr web interface

对于DropWizard和WildFly Swarn，咱们都将使用JBossForgeCLI，以及一些用于建立和与咱们的项目交互的插件：

    • JBoss Forge 3.0+

其余的 Spring IDE 工具(和JBossForge一块儿工做得很好)：

• Eclipse based IDE: JBoss Developer Studio

• Netbeans

• IntelliJ IDEA

最后，当咱们构建和部署咱们的微服务做为运行在Kubernetes内部的Docker容器时，咱们须要如下工具在咱们的机器上的容器环境：

• Vagrant 1.8.1

• VirtualBox 5.0.x

• Container Development Kit 2.x

• Kubernetes/Openshift CLI

• Docker CLI (optional)

原文：

做者源码：https://github.com/redhat-developer/microservices-by-example-source