英语原文共 33 页，剩余内容已隐藏，支付完成后下载完整资料

面向Java开发人员的微服务

第一章

面向Java开发人员的微服务

你能从这本书中得到什么？

本书面向对开发微服务感兴趣的Java开发人员和架构师。我们开始这本书的高水平，公认的和基本的先决条件，应该到位，以取得成功的微服务架构。不幸的是，仅仅使用新技术并不能神奇地解决分布式系统问题。我们来看看其中的一些力量，以及成功的公司为使微型服务为他们服务所做的工作，包括文化、组织结构和市场保障。然后，我们深入研究了一些用于实现微服务的Java框架。随附的源代码repos-iTory可在GitHub。一旦我们弄脏了我们的手，我们将重新开始讨论有关部署、集群化、故障转移以及Docker和Kubernetes如何在这些领域交付解决方案的问题。然后，我们将以Docker、Kubernetes和NetflixOSS为例，介绍它们为云本机微服务体系结构带来的强大功能。在结束我们的想法，我们不能涵盖在这本小书，但也同样重要，如配置，日志记录，和连续交付。

微型服务不仅仅是技术上的讨论。微观服务的实施有复杂的适应性理论、服务-副设计、技术演进、领域驱动设计、依赖思维、承诺理论等背景。他们聚在一起是为了让一个组织的人真正

1

展示敏捷，反应灵敏，学习的行为，以保持竞争力在快速发展的商业世界.让我们仔细看看。

你在一家软件公司工作

软件真的在吞噬这个世界。企业正慢慢开始意识到这一点，这一现象有两个主要的驱动因素：通过高质量的服务提供价值和快速的技术电子化。这本书主要是一种亲自动手的，由例子组成的格式.但是，在我们深入研究这项技术之前，我们需要正确地设置舞台，并了解所起作用的力量。我们最近几年一直在谈论关于做生意的令人恶心的事情。敏捷但我们需要充分理解这意味着什么。否则，这只是一个很好的陈词滥调，每个人都遮遮掩掩。

服务价值

100多年来，我们的商业市场一直致力于产品的更新和推动消费者对这些产品的需求：办公桌、微波炉、汽车、鞋子等等。这种“生产者主导”经济背后的理念来自亨利·福特(HenryFord)的观点：“如果你能以低成本生产出大量的产品，市场几乎是无限的。”要做到这一点，你还需要几个单向渠道直接向群众推销，让他们相信他们需要这些产品，这样他们的生活就会得到改善。在20世纪的大部分时间里，这些单向频道以电视广告、报纸杂志广告和公路广告牌的形式存在。然而，这种以生产者为主导的经济已经被颠覆了，因为市场上充斥着产品(你需要多少部手机/汽车/电视？)此外，互联网以及社交网络正在改变企业与消费者互动的动态(更重要的是，消费者如何与消费者互动)。

社交网络让我们，作为消费者，可以更自由地与彼此以及与我们合作的公司分享信息。我们更信任我们的朋友、家人和其他人，而不是信任营销部门。这就是我们去社交媒体选择餐馆、酒店和航空公司的原因。我们以评论、推特、股票等形式的正面反馈有利于公司的品牌，而我们的负面反馈也同样容易和非常容易迅速摧毁一个品牌。如今，与公司及其消费者之间存在着前所未有的双向信息流动，企业正努力跟上不拥有自己品牌所带来的影响。

后工业企业正在学习，他们必须培养他们与客户的关系(使用双向沟通)，以了解如何为他们带来价值。公司通过服务、客户体验和反馈来支持正在进行的对话。客户根据哪些服务给他们带来了价值和良好的经验，选择了消费和支付的服务。以优步为例，它既不拥有任何发明保守党，也不销售产品本身。坐在别人的车里，我没有任何价值，但通常我会尝试去某个地方(例如，一个忙碌的会议)，这确实会带来价值。通过这种方式，Uber和我通过使用它的服务创造了价值。展望未来，企业将需要专注于为客户提供有价值的服务，而技术将通过数字服务推动这些服务

技术商品化

科技与经济学、生物学和法律一样，也经历了一个从繁荣到萧条的周期。它带来了伟大的创新，如蒸汽机、电话和计算机。在我们竞争激烈的市场中，无论什么时候，改变游戏规则的创新都需要大量的投资和建设，以迅速利用各自的市场。这带来了更多的竞争，更大的产能，以及不断下降的价格，最终使一度创新的技术成为一种商品。在这些商品上，我们继续创新和区分，循环继续。这种商品化把我们从

大型机到个人电脑，我们现在称之为“云计算”，这是一项服务，为我们提供商品计算几乎没有前期资本支出。在云计算之上，我们现在正在以数字服务的形式带来新的创新。

开源也是技术领域的领头羊。在商品化曲线上，开源是一个可以挑战专有厂商的地方，他们可以通过构建和创新曾经只有(没有源代码的)高许可成本的软件来挑战专有供应商。这促使社区构建操作系统(Linux)、编程语言(GO)、消息队列(ApacheActiveMQ)和Web服务器(Httpd)。即使是最初拒绝开放源码的公司也开始通过开源技术和为现有社区做出贡献的方式开始出现。随着开放源码和开放生态系统已经成为常态，我们开始看到许多软件技术的创新直接来自开源社区(例如ApacheSPark、Docker和Kubernetes)。

干扰

这两个因素结合在一起，即服务设计和技术演进，降低了任何有好主意开始尝试和尝试构建新服务的人进入的门槛。你可以学习编程，使用先进的框架，利用按需计算几乎一无是处。你可以发布到社交网络，博客，并与潜在用户进行双向对话，您的服务免费。随着我们商业市场的流动性，任何一家周末以上的初创公司都会让一家老牌公司倒闭。

这一事实让大多数首席信息官和首席执行官感到害怕。随着软件迅速成为公司构建数字服务、经验和差异化的机制，许多人认识到，他们必须成为各自垂直的软件公司。大规模外包和将IT视为商品或成本中心的日子一去不复返了。为了让公司保持真正的竞争力，他们必须接受软件作为一个区别因素，要做到这一点，他们必须接受组织的敏捷性。

拥抱组织敏捷

20世纪工业时代的公司并不是为了敏捷性而建立起来的。它们的建立是为了最大限度地提高效率，减少过程中的各种能力，消除工人中的创造性思维，并将工人放置在盒子里，就像你组织装配线一样。它们就像一台机器，用于接收输入，应用高度调整的过程，并创建输出。它们采用自上而下的分层管理结构，以便于这种机器式的思考。更换机器需要18个月的计划周期。来自边缘的信息要经过许多层的管理和翻译才能到达顶峰，在那里做出决定并将其传回。这种组织方法在创建产品和试图挤压流程中的每一小部分效率时都非常有效，但对于交付服务却不起作用。

顾客不适合在整洁的盒子或过程。他们随时都会出现。他们想要与客服代表交谈，而不是一个自动电话系统。他们要菜单上没有的东西。他们需要输入表单上没有的内容。顾客想要方便。他们想谈一谈。如果他们要等的话就会生气。

这意味着我们面向客户的服务需要对Vari-ability进行核算。他们需要能够对突发事件做出反应。这与效率不符。客户希望通过你提供的服务进行交谈，如果这种服务对解决他们的需求不够，你需要响亮、快速的反馈，说明是什么帮助解决了他们的需求或阻碍了他们。这个饲料-

服务的维护人员可以使用Back来快速调整服务和交互模型，以更好地适应用户。你不能等待决策达到顶峰，并经历18个月的计划周期；你需要迅速做出决定，充分利用你在企业边缘的信息。你需要自动管理、目标驱动、自我组织的团队，这些团队负责向客户(付费客户、业务合作伙伴、同行团队等)提供有吸引力的体验。快速的反馈周期、自主的团队、共同的目标和对话是组织必须接受的先决条件，以便能够导航和生活在一个后工业的、未知的、未知的业务中断中。

如果没有引用Con-way定律：“设计系统hellip;的组织”，任何一本关于微服务的书都是不完整的。而这些设计是这些组织的通信结构的副本。“

要构建敏捷软件系统，我们必须从构建敏捷组织结构开始。这种结构将促进我们需要的微服务的前提站点，但是我们使用的是什么技术呢？构建分布式系统是很困难的，在后面的部分中，我们将研究在构建和设计这些服务时您必须记住的问题。

什么是微服务架构？

Microservice体系结构(microservice Architecture，MSA)是一种构建软件系统的方法，它将业务域模型分解为由服务实现的更小、一致、有界的上下文。这些服务器集是独立的、自治的，但它们之间进行通信以提供一些业务功能。Microservices通常是由小型团队管理的，具有足够的自主权，每个团队和服务都可以更改其内部实现细节(包括直接替换它！)对系统其他部分的影响最小。

团队通过承诺，这是一种服务可以向希望使用该服务的其他组件或系统发布意图的方式。他们用他们的服务接口并通过记录他们的服务的wiki来指定这些承诺。如果没有足够的文档，或者API不够清晰，服务提供商就没有完成他的工作。在下一节中，将更多地介绍承诺和承诺理论。

每个团队将负责设计服务，为问题集选择合适的技术，并在凌晨2点部署、管理和唤醒。任何问题。例如，在Amazon，只有一个团队拥有在结帐过程中调用的税务计算功能。服务范围内的模式(项目、地址、税收等)是否都理解为“在计算税款的范围内”用于结帐；对于这些对象没有混淆(例如，项目是返回项还是结帐项？)拥有税务计算服务的团队设计、开发和运营这项服务.Amazon拥有一套成熟的自助服务工具，可以使许多构建/部署/操作步骤自动化，但我们将回到这一点。

使用微服务，我们可以确定服务的范围，这有助于我们：

·理解服务正在做什么，而不卷入更大的应用程序中的其他问题

·在本地快速构建服务

·为这个问题选择合适的技术(大量的写作？)很多问题？低延迟？突发？)

什么是微服务体系结构？

·测试服务

·在业务所需的频率上构建/部署/发布可能独立于其他服务的业务

·在需要时识别和水平缩放体系结构的各个部分

·提高整个系统的复原力

MicroServices帮助解决了“如何使我们的服务和团队在规模上快速发展？”问题。它允许团队专注于提供服务并在必要时进行更改，并且在不需要花费昂贵的同步点的情况下这样做。一旦您采用了微服务，以下是您不会听到的内容：

·吉拉票

*不必要的会议

共享图书馆

·企业范围内的规范模型

微服务架构适合你吗？微型服务有很多好处，但它们也有自己的缺点。您可以将微服务看作是对需要快速改变事物的能力的问题的优化。效率不高。它可以是更多的资源密集型。你可能最终会出现类似复制的现象。操作的复杂性要高得多。从整体上理解这个系统变得非常困难。调试问题变得非常困难。在某些领域，您可能需要放宽事务的概念。团队可能不是为这样的工作而设计的。

并不是生意的每一个部分都能在一毛钱上改变。很多面向客户的应用程序都这样做。后端系统可能不会。但是，当这两个世界开始融合在一起时，我们可能会看到支持微服务体系结构的力量向系统的其他部分推进。

挑战

按照微服务方法设计云本地应用程序需要对如何构建、部署和操作它们进行不同的思考。我们不能就这样构建我们的应用程序

知道它会失败的所有方式，然后防止这些。在像微型服务这样复杂的系统中，我们必须能够处理不确定性。本节将确定在开发微服务时要记住的五个主要事项。

故障设计

在复杂的系统中，事情会失败。硬盘崩溃，网络电缆断开，我们对实时数据库进行维护，而不是备份，VM就消失了。单个故障可以传播到系统的其他部分，导致级联故障，使整个系统瘫痪。

传统上，在构建应用程序时，我们试图预测应用程序的哪些部分(例如，n层)可能会失败，并建立一堵足够大的墙，以防止出现故障。这种心态在规模上是有问题的，因为我们不能总是预测复杂系统中会出现什么问题。物物将要失败，所以我们必须发展我们的应用程序，以适应和处理失败，而不仅仅是防止它。我们应该能够很好地处理故障，而不是让故障传播到整个系统的故障。

构建分布式系统不同于构建共享内存、单进程、单片应用.一个明显的不同之处在于，网络上的通信不同于具有共享内存的本地调用。网络本质上是不可靠的。由于各种原因(例如信号强度、不良电缆/路由器/交换机和防火墙)，网络呼叫可能失败，这可能是瓶颈的主要来源。网络不可靠不仅对您的服务客户端的响应时间有性能影响，而且还可能导致上游系统故障。

潜在的网络调用很难调试；理想情况下，如果您的网络调用无法成功完成，它们就会立即失败，您的应用程序很快就会注意到(例如，通过IOException)。在这种情况下，我们可以快速采取纠正措施，提供降级的功能，或

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[604830]，资料为PDF文档或Word文档，PDF文档可免费转换为Word