1.简介

微服务 ， 微服务 ， 微服务 ......一个在行业时下最热门的话题，每个人都在新的闪亮的东西想干什么，往往没有真正思考的深刻和深远的变革这种建筑风格既需要来自人民和组织的观点。

在本教程中，我们将讨论实用的微服务体系结构 ，从核心原则开始，逐步向使其投入生产的方向发展。 在这个领域中正在发生大量的创新，因此请带着一些细微的注意来完成我们将在本教程中讨论的所有内容：今天公认的实践明天可能不会兑现其诺言。 不论好坏，该行业仍在积累有关开发和运营微服务的专业知识并获得经验。




目录


1.简介

2.我们周围的巨石

3.说“是！”

到微服务

3.1。

建筑内部的建筑

3.2。

有界上下文

3.3。

所有权

3.4。

独立部署

3.5。

版本控制

3.6。

正确的工作工具

4.散装巨石的危险

4.1。

每个功能（可能）是一个远程调用

4.2。

闲谈

4.3。

依赖周期

4.4。

分享分享

5。结论

6.接下来



关于以“正确的方式”进行微服务的意见不一，但事实是，实际上并没有神奇的配方或建议能使您到达那里。 这是一个不断学习和改进的过程，同时尽您最大的努力来控制复杂性。 请不要将本教程中讨论的所有内容视为理所当然，保持开放的态度，不要害怕挑战。

如果您想扩展自己的书架，那么有关此问题的文献还很少，但是Sam Microman的《 构建微服务：设计精细系统 》和 Irakli Nadareishvili的《微服务 架构：对齐的原则，实践和文化》无疑是值得一读的书。拥有和阅读。

2.我们周围的巨石

多年来，传统的单层体系结构或/和客户端/服务器体系结构 （实际上，瘦客户端与强大的服务器通信）是构建软件应用程序和平台的主要选择。 可以说，对于大多数项目来说，它都能很好地工作（并且仍然可以正常工作），但是微服务体系结构的出现突然在所有这些东西上都放上了可怕的整体式标签（许多人将其视为传统 ）。

当围绕技术的炒作可能掩盖常识时，这是一个很好的例子。 Monolith没错，有很多成功的例子可以证明这一点。 但是，确实存在可以限制它们的限制。 让我们简短地讨论一下，并概述一些希望采用微服务体系结构的关键原因。

不管喜欢与否，在许多组织中， 巨石是大泥球的代名词。 维护成本飞速增长，错误和退化的数量不断增加，从而降低了质量标准，由于开发人员需要太多时间来实施，因此业务在交付新功能方面遇到了困难。 这似乎是回顾和分析出了什么问题以及如何解决的好机会。 在许多情况下，将大型代码库拆分为具有完善的API的一组内聚模块（或组件）（本身不必更改打包模型）可能是最简单，最便宜的解决方案。

但是通常您可能会遇到可伸缩性问题，包括扩展软件平台和扩展工程组织，这在遵循整体架构时很难解决。 著名的康威定律很好地概括了这一点。

“……设计系统的组织……受到约束而无法制作设计，这些设计是 这些组织 的通信 结构 的 副本 。” – http://www.melconway.com/Home/Committees_Paper.html

微服务会成为隧道尽头的亮点吗？ 绝对有可能，但请准备好大幅度更改您过去遵循的工程组织和开发实践。 当然，这将是一个坎ride的旅程，但应该在本教程的开头部分强调，我们不会质疑架构选择（并将您推向微服务 ），而是假设您进行了研究并坚信微服务是您要寻找的答案。

到微服务

那么，术语“微服务”和“微服务架构”实际上是什么意思？ 您可能会发现有很多稍微不同的定义，但可以说最完整，最易理解的定义是Martin Fowler在其关于微服务体系结构的文章中提出的：

简而言之，微服务体系结构样式是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。 这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。 – https://www.martinfowler.com/articles/microservices.html

前缀“ micro”成为不断混乱的根源，因为它应该以某种方式确定服务的规模。 毫不奇怪，事实证明要证明其正确性是相当困难的。 良好的经验法则是，以这样一种方式拆分系统，即每个微服务都有一个有意义的目标可以实现。 “微”规模的另一个有争议的定义是，微服务应足够小以适合一个开发人员（或更正式地说，是维护者）的头。

基本上有两种方法可以指导您采用微服务体系结构 ：启动未开发的应用程序或发展现有的微服务体系结构 （很可能是整体式 ）。 为了通过任何一条路线开始旅途中的成功，需要注意许多先决条件和原则。

首先， 微服务都是关于正确完成领域建模和领域设计的。 有两本与众不同的书， 《域驱动的设计： 埃里克·埃文斯 （ Eric Evans）撰写的《解决软件核心中的复杂性》和沃恩·弗农 （ Vaughn Vernon）的《 实现域驱动的设计》 ，这是该主题的可靠来源，并强烈推荐阅读。 如果您不太了解自己的业务领域，那么唯一的建议就是继续打开微服务的大门。

稍后，它的重要性将变得很明显，但是当您从头开始开发应用程序时，这是一个非常困难的问题，因为方程中的未知数太多。

3.1架构内部的架构

总体而言， 微服务架构要求将您的应用程序结构化为一组适度的服务，但并不指示应如何实现服务（以及它们之间的通信）。 从某种意义上讲，它可以认为是某种顶级架构。

因此，应用于各个微服务的架构选择各不相同，在许多其他应用中，经常可以在野外看到六角形架构 （也称为端口和适配器 ）， 干净架构 ， 洋葱架构和旧的伙伴分层架构 。

3.2有界上下文

有限上下文的定义直接来自领域驱动的设计原则。 当应用于微服务体系结构时 ，它概述了每个微服务负责的业务子域的边界。 有限的上下文成为微服务契约的基础，并且实质上是通往外部世界的篱笆。

整个应用程序的累积业务域模型由其所有微服务的域模型组成，它们之间具有有限的上下文将它们粘合在一起。 显然，如果业务域的定义和分解不明确，那么它们前面的域模型，边界上下文和微服务也是如此。

3.3所有权

每个微服务都必须充当其所管理域（包括其拥有的数据）的唯一真实来源。 切断数据共享的任何诱惑（例如，直接咨询数据存储）是非常重要的，因为这样可以绕开合同微服务。

实际上，事情永远不会完全孤立，因此应该有解决方案。 确实，由于数据共享不是一种选择，因此您将立即面临重复某些片段的需求，因此，找到了一种使它们保持同步的方法。

您将要进行的每个实现更改都应该明确地分解为各个部分，并放入正确的微服务（或一组微服务）中。

从组织的角度来看，所有权转化为为每个微服务（或也许有几个微服务）拥有一个专门的跨职能团队。 跨功能方面是朝着成熟和最终责任迈出的重要一步： 构建它，运输它，运行它并支持它 （或者简单地说， 构建，拥有它 ）。

3.4独立部署

每个微服务都应彼此独立：不仅在开发期间，而且在部署期间。 单独的部署，最重要的是独立扩展的能力，是微服务架构背后的最强大力量。 将微服务视为独立于平台和基础架构的自治单元，随时可以在任何地方进行部署。

3.5版本控制

独立也意味着每个微服务都应具有自己的生命周期和发行版本。 这是关于所有权的讨论的一种结果，但是这次的重点是协作。 就像在任何松耦合的分布式系统中一样，破坏事物非常容易。 变更必须在所属团队之间进行有效沟通，以便每个人都知道即将发生的事情并可以对此做出解释。

保持向后 （和向前 ）兼容性成为必须的实践。 这是另一个责任感：不仅要确保新版本的微服务正常启动并正常运行，而且现有使用者仍可以正常使用。

3.6正确的工作工具

微服务架构真正包含“为工作选择合适的工具”的理念。 编程语言，框架和库的选择不再固定。 由于不同的微服务需要满足不同的要求，因此，只要微服务可以有效地相互通信，就可以更轻松地混合和匹配各种工程决策。

4.散装巨石的危险

公平地说， 微服务架构可以提供很多功能，但是也会给画面带来很多复杂性。 毫不奇怪，编程语言和/或框架的选择可能会进一步放大这种复杂性。

在决定采用微服务时 ，许多组织和团队陷入了采用与过去相同的开发实践和流程的陷阱。 这可能是最终结果经常成为分布式整体的主要原因，这对于开发人员来说是一场噩梦，而对于运营来说却是恐怖。 让我们谈论一下。

4.1每个功能（可能）是一个远程调用

由于每个微服务都生活在某个地方的单独进程中，因此每个函数调用都可能导致对上游微服务的网络调用风暴。 这里的边界可能是隐式的，在代码中不容易发现，因为从第一天起就必须提供适当的工具。 网络呼叫很昂贵，但最重要的是，一切都可能以惊人的方式失败。

4.2聊天

通常，一个微服务需要与其他一些上游微服务进行通信。 这绝对是正常的和预期的做法。 但是，当所涉及的微服务需要调用其他数十个微服务 （或向另一个微服务发出大量调用以完成其任务）时，很明显，拆分未正确完成。 高水平的交谈不仅受网络延迟和故障的影响，还表明存在无用的中介者或无法代理的人。

4.3依赖周期

聊天的极端形式是微服务之间存在直接或间接的循环。 周期通常是看不见的但非常危险的野兽。 即使您发现了将此类相互依赖的微服务部署到生产中的魔幻顺序，它们迟早也会将应用程序推倒。

4.4分享

管理微服务之间的共同点是特别难以解决的问题。 多年来，作为开发人员，我们已经学到了许多最佳实践和模式。 在其他方面， DRY和代码重用原则脱颖而出。

确实，我们知道代码重复（也称为复制/粘贴编程 ）是不好的，应该不惜一切代价避免。 但是，在微服务架构的上下文中，不同微服务之间共享代码会引入最高级别的耦合。

您可能会完全摆脱共享库之类的想法，这是非常不现实的（尽管值得一试），特别是当您使用相同的编程语言或平台编写微服务时。 在这种情况下，目标是要掌握将共享件的数量减少到绝对必要的最低限度的理想方法，理想情况下是没有。 否则，这种共享将把您拖入整体式的方式，但是这次是分布式的。

5。结论

在本节中，我们简要地讨论了微服务架构 ，在桌面上带来的好处，引入的复杂性以及为工程组织带来的重大变化。 这种建筑风格带来的机遇是巨大的，但另一方面，错误的代价也同样很高。

6.接下来

在本教程的下一部分中，我们将讨论经证实非常适合微服务体系结构的典型服务间通信样式。

翻译自: https://www.javacodegeeks.com/2018/07/microservices-for-java-developers-introduction.html