作者：王磊
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
微服务架构与实践试读：
前言
本书的结构
本书一共分为3个部分，分别是基础篇、策略篇和实战篇。基础篇为第1章，主要介绍微服务架构相关的基础知识。该章首先介绍软件架构的演进史；其次阐述了微服务出现的背景、定义、特征及落地时面临的挑战；同时分析了微服务与SOA、Serverless的关系；最后介绍了微服务领域Service Mesh的兴起。阅读的重点为理解微服务的本质特征、挑战并了解Service Mesh。
策略篇包含第2章至第6章，主要介绍了微服务生态系统、微服务关键技术、微服务实施参考模型以及基于参考模型的实践，并在本篇最后的部分阐述了遗留系统改造的策略与案例。
第2章首先介绍了微服务生态系统，并围绕生态系统阐述微服务实现中涉及的接入层、业务层、支撑层及基础设施。同时，也强调了开发框架、交付流水线与工程实践的重要性。阅读的重点是理解微服务生态系统的核心，系统化地思考微服务架构的演进过程（不仅仅是服务拆分），并在演进中持续提升团队能力。
第3章的内容是对第2章内容的延伸，详细介绍了微服务的设计（服务划分策略、服务设计模式、内部实现结构等）、微服务治理（负载均衡、注册发现、容错机制等）的原理及方案、服务运维（监控告警、日志聚合等）的实践等。第3章内容的重点是微服务的划分策略、服务设计模式以及服务治理。一直以来，如何有效拆分服务是很多朋友在微服务落地过程中遇到的一大挑战，希望该部分的内容能为读者提供一些思路。
第 4 章是策略篇的核心内容，详细介绍了微服务参考模型的 3 个方向、8 个维度与 5个阶段，同时梳理出在微服务落地过程中，如何借助结果类、过程类两类指标获取反馈并持续改进。需要注意的是，模型中提到的阶段定义以及度量指标，是笔者基于过往的项目经验所总结，不一定能完全适用于所有项目，希望读者能在此基础上，制定适于团队的参考指标。
第5章基于参考模型总结了持续交付、部署运维、全功能团队等多个维度下的工程实践。虽然该部分的介绍可能涉及一些具体的工具（如 RPM、FPM、Koji 等），但建议读者将把更多的注意力放到实践本身。工具是具体的，但实践是普世的。读者朋友可以基于这些实践举一反三，结合不同的工具、平台助力微服务的落地。
第6章阐述了遗留系统的不同改造策略及应用场景，并用基于笔者亲历的一个案例阐述了遗留系统的改造思路和服务化演进过程，希望能为正在对遗留系统进行改造的读者提供启发。
实战篇包含第 7 章至第 13 章，在前两部分的基础上，基于开源的微服务框架ServiceComb以及华为云ServiceStage设计和实现了SockShop系统，同时基于ServiceStage提供的流水线，将SockShop系统以持续交付的方式部署在公有云上。另外，使用ServiceStage提供的运维服务，对SockShop系统进行监控、告警和日志聚合。
第7章介绍了ServiceComb的特性、原理，注册中心的设计以及数据一致性解决方案Saga的设计。读者既可以学习到如何快速开始实施ServiceComb项目，也能深层次地了解其背后的设计原理与细节。
第8章主要介绍了华为云ServiceStage提供的相关服务。
第9章分析和设计了SockShop系统，并进行了服务设计、技术选型以及环境准备，确保在后面的章节中，能快速进行服务的开发、测试、持续集成和自动化部署。
第10章介绍了使用ServiceComb和Java Chassis实现第一个微服务，并搭建端到端的开发、测试、验证、持续交付流水线，同时应用了多个维度下的工程实践。
第11章介绍了如何实现SockShop系统的其他服务，并通过Service Mesh的机制，将用户界面服务接入SockShop系统。
第12章介绍了SockShop系统的服务编排。通过使用定义好的TOSCA模版上，基于ServiceStage的编排服务，快速地进行SockShop系统的自动化部署。
第13章介绍了ServiceStage提供的APM相关服务，并基于APM对SockShop系统进行运维。
阅读指南
本书每个部分，甚至很多章节的内容都相对独立，读者可以按顺序阅读，也可以选择不同的章节直接阅读。我们将读者对微服务的了解分为三个阶段，初学阶段、中级阶段和高级阶段，处于不同阶段的读者可以按照下面的阅读指南来选择性地阅读本书。
● 初学阶段：可以先阅读第1部分了解微服务相关的基础知识，然后阅读第3部分，尝试自己动手实现微服务，搭建流水线并部署微服务，有所体会后再回过头查看第2部分的内容。
● 中级阶段：可以先阅读第1部分中微服务的最新进展，如Service Mesh等，然后阅读第2部分的内容，最后选择性地阅读第3部分的内容。
● 高级阶段：选择性地阅读第1部分中微服务的最新进展，然后阅读第2部分的参考模型以及实践的章节。如果对ServiceComb框架感兴趣，也可以阅读该部分的设计与实现。
本书中的DevOps
在本书的基础篇中，笔者提出微服务的本质是“以缩短交付周期为核心、基于DevOps的演进式架构”，可以看出在微服务的落地过程中，与DevOps是相辅相成的。另外，在策略篇中，本书提到的很多实践也是和DevOps提倡的“CALMS”理念相吻合的。但本书并不是一本探索如何实施 DevOps 的书，更多的内容还是从架构、工程以及组织等维度阐述如何有效落地微服务。如果读者希望系统地学习DevOps，建议参考其他DevOps类的相关书籍，如《DevOps实践指南》或《DevOps实施手册》等。
本书的源码
本书中提到的源码，可以通过正文后的“资源列表”中的地址获取。第1部分 基础篇第1部分为基础篇，介绍应用架构的演进历程以及微服务诞生的背景，并通过对微服务概念、特征的探讨，帮助读者深刻理解微服务的本质。同时，本部分的内容也客观地阐述了实施微服务时所面临的挑战。另外，随着微服务相关实践在业界的成熟，新的工具和理念不断涌现，如Serverless、Service Mesh等，这也使我们可以更高效地构建微服务。在本部分中，笔者也会对这些技术一并进行探讨。基础篇的主要内容包括：● 软件架构发展回顾以及微服务诞生的背景。● 微服务架构的本质及落地时面临的挑战。● 微服务与SOA、Serverless的关系。● 下一代微服务Service Mesh。第1章 微服务架构综述
微服务架构模式（Microservice Architecture Pattern）是近几年在软件架构模式领域里出现的一个热词。虽然其诞生时间不长，但在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件领域所带来的深远影响。
随着业务的快速变化以及竞争的不确定性，传统的软件系统架构正面临着诸多挑战。而微服务，正如Gartner所预测的那样，正在为新一代的软件架构，如快速响应、容错、按需伸缩等特性产生积极的推动作用。
那什么是微服务架构？它的本质是什么？和传统的面向服务架构（SOA）相比，它有什么样的异同点？它是我们所期望的架构领域的“银弹”吗？在过去的几年中，它有着怎样的发展？它与Serverless、Service Mesh等新技术，有着怎样的联系？未来它又会有怎样的发展趋势？本章将一一解答上述问题，揭开微服务的神秘面纱。1.1 软件架构发展历史
什么是软件架构
和建筑领域的架构相似，软件架构是软件系统的高层次结构，通过这些结构可以推理软件系统，了解每个结构包含的软件元素，元素之间的关系以及元素、关系等的属性。IEEE认为软件架构是关于“软件密集型系统”的架构，并将其定义为“软件对整个系统的设计、构建、部署和演进产生重大影响的任何系统”，不仅包括硬件和软件，还包括“人类、过程、程序、设施、材料和自然发生的实体”。
ANSI/IEEE 1471-2000 IEEE Recommended Practice for Architectural Description for Software-Intensive Systems
软件架构是对复杂系统的结构进行抽象，它帮助我们在系统实现前，对软件系统进行元素重用、行为分析和决策提供基础。软件架构也体现了组织沟通的结构（康威定律），同时也影响了系统实施的实践以及维护的难度。
单体架构（Monolithic Architecture）
计算机科学领域自成立以来就遇到了与复杂性有关的问题。开发人员通过选择正确的数据结构，开发算法以及应用关注点分离的概念来解决早期的复杂问题。当时的企业组织结构多为功能型组织，同时服务只能部署在性能、可靠性强大但价格不菲的大型机上。在这样的条件下，应用的呈现、逻辑处理和数据存储等功能，都集中部署和运行在同一台服务器上，通常称为单体架构。
此时，应用以及其部署的服务器承担处理大部分的任务，对应用的访问通常通过没有处理能力的哑终端进行。随着硬件价格降低，哑终端逐渐演化为拥有一定处理能力的智能终端，逐渐发展为客户端-服务器（C/S）的模型。根据客户端和服务器端承担的处理任务的多少，这种模型会有多种变体。其带来的主要挑战是需要维护和更新所有用户的客户端。进而导致了浏览器客户端（B/S）模型的产生，通过统一的客户端，向服务器发起HTTP请求，然后跟据响应渲染浏览器的UI。
哑终端是在早期的类UNIX操作系统的计算机系统上使用的一个术语，一般特指只能输入、输出和显示字符的终端，即字符终端。哑终端本身不具备计算能力。
分层架构（Layered Architecture）
随着服务器开始在Web世界中承担更多的职责，如服务UI、事务处理、数据存储等，由于受到面向过程的思维及设计方式的影响，所有的逻辑代码并没有明显的区分，因此代码之间的调用相互交错，错综复杂。
另一方面，面向对象分析、面向对象设计、设计模式、企业架构模式等理念及方法论的不断发展，从为用户提供功能及有效组织软件结构的角度考虑，架构师将这些职责划分为各个逻辑层（UI层、业务层、数据层等）来简化复杂性。每一层负责的部分更趋向于具体化、细致化，于是软件的分层架构（Layered Architecture）逐渐出现。
在分层架构中，数据库作为系统组件不需要实现，所以典型的分层架构通常包括表示层、业务逻辑层以及数据访问层，如图1-1所示。图1-1 软件的分层架构
● 表示层
表示层的部分指当用户使用应用程序时，看见的、听见的、输入的或者交互的部分。譬如，有可能是信息的显示、音乐的播放，或者可以输入的文本框、单选按钮，以及可点击的按钮等。通过这些元素，用户同软件进行交互并获取期望的价值。目前的用户界面在大部分情况下为Web方式，当然也可以是桌面软件的形式，例如.NET的WINFORM或者Java的SWING。
● 业务逻辑层
业务逻辑部分是根据用户输入的信息，进行逻辑计算或者业务处理的部分。业务逻辑层主要聚焦应用程序对业务问题的逻辑处理，以及业务流程的操作，它是大部分软件系统区别于其他系统的核心。譬如，当用户单击一个按钮后，它可能会触发业务逻辑部分的代码进行运算，生成用户期望的结果。举例来说，在一个电子商务平台中，作为用户，当我们下单购买某商品后，应用程序的业务逻辑层会对订单进行处理，如计算折扣、进行配送等。
● 数据访问层
在用户同应用程序交互的过程中，会产生数据。这类数据需要通过某种机制有效地保存，并在将来能够被重复使用，或者提供给其他系统。这种机制或者方法就是数据访问层最关注的部分。也就是说，它关注的是应用程序是如何有效地将数据存储到数据库、文件系统或者其他存储介质中。有一点要注意的是，它关注的是对原始数据的操作（数据库或者文件系统等存取数据的形式以及接口），而非原始数据的存储介质本身（数据库或者文件系统本身）。
三层架构的出现，一方面是为了解决应用程序中代码间调用复杂、代码职责不清的问题。其通过在各层间定义接口，并将接口与实现分离，可以很容易地用不同的实现来替换原有层次的实现，从而有效降低层与层之间的依赖。这种方式不仅有利于帮助团队理解整个应用架构，降低后期维护成本，同时也有利于制定整个应用程序架构的标准。
另一方面，三层结构的出现从某种程度上解决了企业内部如何有效根据技能调配人员、提高生产效率的问题。在大环境下，有效地分层能使不同职责的人员各司其职，更聚焦于个人专业技能的发展和培养。
虽然软件的三层架构将应用在逻辑上分成了三层，但它并不是物理上的分层。这也就意味着，这些不同层的代码经过编译（非静态语言则忽略编译阶段）、打包、部署后，如果不考虑负载均衡以及水平扩展的情况，最终还是运行在同一个机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单体应用。
典型的单体应用，莫过于传统的J2EE项目所构建的产品或者项目，它们存在的形态一般是WAR包或者JAR包。当部署这类应用时，通常将其作为一个整体，部署在同一个Web容器，如Tomcat或者Jetty中。当这类应用运行起来后，所有的功能也都运行在同一个进程中。单体应用如图1-2所示。图1-2 单体应用
和大型机时代不同，小型机时代的物理服务器价格已经很便宜了，作为另一种选择，我们也可以将不同的层部署到不同的物理服务器上，以实现层之间的解耦。
综上所述，单体应用其实是基于分层软件架构设计，从部署模式、运行模式角度考虑的一种概念。
单体应用的优势非常明显，在产品开发初期，由于是单进程、单部署包，因此代码的变更、测试、部署和水平伸缩都相对容易。但是，随着产品复杂度的增加以及代码库的膨胀，单体应用的维护成本和变更难度会呈指数级增长，带来诸多挑战：
● 交付周期长。
● 缺陷定位、修复问题的成本高。
● 新人培养周期。
● 采用新技术的成本增加。
● 无法按功能实现水平扩展。
要解决这些挑战，需要在应用架构层面发生改变。
SOA（面向服务的架构）
为了帮助业务快速、高效地响应市场变化，面向服务的架构（SOA）产生了。SOA是一种软件设计风格，通过网络通信协议，将应用程序/组件作为服务提供给其他使用者。面向服务架构的基本原则是“服务是一个独立的功能单元，可以远程访问并独立执行和更新。”典型SOA结构如图1-3所示。图1-3 典型SOA结构（引用自wikipedia）
早在1996年，Gartner就提出了SOA的概念，阐述了“对于复杂的企业IT系统，应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务”，其目的是为解决企业内部不同IT资源之间无法互联而导致的信息孤岛问题。2002年，SOA被称作"现代应用开发领域最重要的课题之一"，其正在帮助企业从资源利用的角度出发，将IT资源整合成可操作的、基于标准的服务，使其能被重新组合和应用。
由于SOA本身的广义性以及抽象性，在其诞生的相当长一段时间内，人们对SOA存在着不同的认知和理解。
直到2000年左右，ESB（Enterprise Service Bus）、WebService、SOAP等这类技术的出现，才使得SOA渐渐落地。同时，更多的厂商，像IBM、Oracle等也分别提出基于SOA的解决方案或者产品。
根据SOA的定义，服务具有以下4个属性：
● 逻辑上代表具有特定结果的业务活动。
● 独立性。
● 以黑盒的形式呈现给消费者。
● 可包含其他基础服务。
不同的服务可以联合使用，以提供大型软件应用程序的功能。上面的定义看起来像是模块化编程，但SOA本身并不是模块化应用，其更多解决如何通过分布式、单独部署和维护的服务来组成应用程序。
很多企业架构师认为SOA可以快速、高效应对业务变化，促进了服务而不是代码层面的重用。但SOA面临的主要挑战是通信协议带来的性能损耗、元数据的管理以及测试成本高。这给SOA的大规模实施带来了一定的困难。随着市场需求的快速变化，单体应用或者SOA的维护、缺陷修复、架构演进、系统扩展等成本在显著增加。另一方面，
试读结束[说明：试读内容隐藏了图片]