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