作者：程超 等
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
高可用可伸缩微服务架构：基于Dubbo、Spring Cloud和Service Mesh试读：
前言
微服务这个概念最早是在 2011 年 5 月在意大利威尼斯的一个软件架构会议上讨论并提出的，用于描述一些作为通用架构风格的设计原则。2012 年 3 月在波兰克拉科夫举行的“第 33届学位会议”上，ThoughtWorks公司的首席咨询师James Lewis做了题为“Microservices-Java，the Unix Way”的演讲（http：//2012.33degree.org/talk/show/67），这次演讲里James讨论了微服务的一些原则和特征，例如单一服务职责、康威定律、自动扩展、DDD等。
微服务架构则是由 Fred George 在 2012 年的一次技术大会上所提出的（http：//oredev.org/oredev2012/2012/sessions/micro-service-architecture.html），在大会的演讲中，他讲解了如何分拆服务，以及如何利用MQ来进行服务间的解耦，这就是最早的微服务架构的雏形。而后由Martin Fowler 发扬光大，并且在 2014 年发表了一篇著名的文章（https：//martinfowler.com/articles/microservices.html），这篇文章深入全面地讲解了什么是微服务架构。随后，微服务架构逐渐成为一种非常流行的架构模式，一大批的技术框架和文章涌现出来，越来越多的公司借鉴和使用微服务架构。
然而微服务并不能“包治百病”，我们在实施的过程中不能简单地使用某些个微服务框架或组件一蹴而就，而是需要将业务、技术和运维有机地结合起来，配合同步实施，并且在此过程中还需要踩过很多的“坑”才能取得成功。
本书的每一个章节都是相关领域的专家经过多年的技术积累提炼而成的。秉承以理论为基础，以大量企业实战案例为核心的宗旨。本书深入全面地介绍微服务架构的实施方法，以及在实施过程中所遇到的问题和解决方案，是一本内容翔实、“可落地”的理论与实践相结合的技术书籍。
不忘初心，方得始终
在2017年8月份的一次技术大会上，我与电子工业出版社博文视点公司的编辑陈晓猛相识。我们沟通了很久，并且在很多想法上是高度一致的，由此我萌生了想写一本技术书籍的念头。关于书的主题，我考虑了很久，特别是对于自己近几年的工作经验的思考和总结，最终决定以“微服务”作为主题。
最初我邀请了秦金卫和方志斌作为写作团队的成员。我们三人在创作思路上一拍即合，计划以微服务架构的概念和内容，Dubbo和Spring Cloud的原理和实践，以及我们在工作中的各种思考和最佳实践为主体内容，三人分工协作，创作一本业内前沿的微服务架构书籍。然而写作却是一个漫长的过程，需要的不仅是一腔热血，还需要持之以恒的精神。这个过程中我们三人都因为各自的事情很忙导致写作时停时续，甚至想过放弃，但我们始终没有忘却初心，互相鼓励坚持下去。志斌工作较忙经常出差，以至于我看到他经常在凌晨二三点的时候还在更新文章；金卫一直有很多好的想法，给我们写作提供了很多有用的建议，我们也是经常沟通到半夜。在这个不断有思想火花碰撞的过程中，我们决定增加了一些章节使本书的整体内容更丰富全面、实用性更强。于是我又邀请了梁桂钊、杜琪、张逸、殷琦和肖冠宇五位朋友加入，为本书注入新的能量。桂钊虽然加入较晚，但却非常投入，参与写作了很多章节；杜琪在加入写作之时宝宝还没有降生，现在应该也有半岁了；张逸、殷琦和冠宇在本书快完成之时紧急驰援，高效地完成了各自负责的章节。我们写作团队的成员都不在一个城市，来自祖国各地，但我们为了初心而凝聚在一起，这就是大家的团队精神。
历时近一年半的书即将出版了，我内心的激动难以言表。除了感谢写作团队，我还要感谢编辑陈晓猛对我的不断鼓励和大力支持，感谢好友王文斌提供了好多有用的建议。我也要感谢家人对我的支持，在这本书出版之际，我的儿子多多刚满三岁，我要感谢儿子，让我“借用”了很多原本陪伴他成长的宝贵时间。
最后我想说的是，我们团队不全是微服务架构方面的技术专家，但是大家基于共同的对微服务架构技术的热爱和乐于分享知识经验的精神，我们把微服务架构领域的各类知识，以及自己平常的经验和积累做了完整的梳理和总结，凝结为这样一本技术书，作为2019年的一份礼物呈现给大家，欢迎大家共同探讨和交流。
本书适合的读者
本书讲解如何通过Dubbo、Spring Cloud、Service Mesh等技术来构建微服务体系，并深入浅出地介绍了微服务架构发展历程、领域驱动设计、稳定性保证的常用手段、分布式事务的一致性方案；本书还通过大量的案例探讨微服务落地方案，例如双活体系建设、分布式监控、微服务编排、百亿流量微服务网关的设计与实现、基于支付场景下的微服务改造等；书籍后半部展示了实现微服务架构的完整蓝图，并让读者了解如何借助微服务来增强和重构现有的遗留系统。无论刚接触微服务的新手，还是正在尝试借助微服务解放生产力的开发人员或运维人员，或者是立志于构建高可用可伸缩的微服务体系的架构师，阅读本书，对读者必有裨益。
本书内容
本书共14章，每章的具体内容如下。
第1章：微服务架构概述（作者秦金卫）。
本章从软件架构的发展历程讲起，分别对单体架构、SOA架构和微服务架构的演进过程做了深入浅出的讲解，同时深入介绍了微服务架构的特点，希望以宏观的视角为读者打开微服务的大门。
第2章：微服务领域驱动设计（作者张逸）。
本章介绍了领域驱动设计是什么，常见的领域架构有哪些，如何将领域驱动应用到微服务中，以及如何使用领域驱动进行合理的服务划分等，帮助读者在正式学习微服务前修炼“内功”。
第3章：Apache Dubbo框架的原理与实现（作者程超）。
目前Dubbo已经被阿里巴巴技术团队重新维护并且得到了大力的发展和推广，使用Dubbo可以很好地进行微服务建设，本章较为深入地讲解了Dubbo的使用和技巧，以及通过时源码的深入分析能够让读者对Dubbo的原理实现有一个全面的认识。
第4章：Spring Boot/Spring Cloud实践（作者方志斌）。
Spring Boot/Cloud是目前较为流行的微服务框架，本章以大量的实战案例为线索，为读者讲解如何才能使用好Spring Cloud框架，讲解如何避免在使用过程中“踩坑”。
第5章：微服务稳定性保证的常用手段（作者杜琪）。
在业务发展越来越快，规模也越来越大的情况下，我们所面临的就是如何在服务越来越多的情况下保证微服务架构的稳定性，本章讲解保障稳定性的常用技巧和手段。
第6章：微服务下如何保证事务的一致性（作者梁桂钊）。
本章介绍了从本地事务到分布式事务的演变，深入分析了微服务在强一致性场景和最终一致性场景下的解决方案，探讨了二阶段提交协议、三阶段提交协议、TCC模式、补偿模式、可靠事件模式等。同时，对开源项目的分布式事务进行解读，包括 RocketMQ 和 ServiceComb。
第7章：百亿流量微服务亿级网关的设计与实现（作者秦金卫）。
本章从百亿流量交易系统微服务网关（API Gateway）的现状和面临问题出发，阐述微服务架构与 API 网关的关系，理顺流量网关与业务网关的脉络，分享全面的API网关知识与经验。
第8章：微服务编排（作者程超）。
本章以Netflix Conductor框架为核心，从框架的使用和原理的角度深入介绍了什么是微服务编排，为微服务执行复杂的业务逻辑提供了一种新的思路。
第9章：微服务数据抽取与统计（作者肖冠宇）。
在微服务架构下，服务必将越来越多，在这种情况下进行数据统计和分析将变得非常困难，本章将深入讲解如何从不同服务的数据库中抽取数据到统一的大数据平台中，帮忙使用者更方便地进行数据的统计。
第10章：微服务双活体系建设（作者程超）。
在企业发展规模越来越大的情况下，用户对系统的稳定性要求也越来越高，那么单机房部署势必成为发展的瓶颈，本章将以实际案例出发讲解同城双活的建设。
第11章：基于支付场景下的微服务改造与性能优化（作者程超）。
本章从实际的案例出发，在具体的支付业务场景下，从一个新项目开始逐步讲解如何利用领域驱动划分服务，如何利用微服务框架进行服务治理，以及项目完成后怎样提升微服务架构的性能。
第12章：遗留系统的微服务架构改造（作者梁桂钊）。
本章介绍了遗留系统的微服务架构改造，梳理了代码分层结构的转变，提出一个新的代码分层思路来应对微服务的流行与普及，并深入思考了遗留系统的债券，深入探讨单体系统拆分服务的方法论。同时，对遗留系统的微服务架构改造的解决方案给出9个切实可行的核心实践思路。
第13章：Service Mesh详解（作者殷琦）。
随着微服务的持续发展，下一代微服务架构已然出现，本章将深入介绍Service Mesh的发展历程，以及结合具体案例带领读者使用Istio进行具体实践。
第14章：微服务监控实战（作者程超）。
本章重点介绍APM的原理，从零开始开发APM监控系统，还深入介绍Prometheus的安装和原理，以及如何使用Prometheus进行监控和预警。
作者简介
程超，网名小程故事多，现任某公司高级架构师，超过12年的Java研发经验，8年技术管理和架构经验，熟悉支付和电商领域，擅长微服务生态建设和运维监控，对Dubbo、Spring Cloud和gRPC等微服务框架有深入研究，帮助多家公司进行过微服务建设和改造。合著作品《深入分布式缓存》，阿里云MVP、云栖社区外部专家、Codingfly社区特聘技术专家、CSDN博主专家。
梁桂钊，现任某互联网公司高级开发工程师，参与过内容分发、K12 教育、淘系电商等项目。目前，专注于新零售电商服务的业务摸索和电商服务创新实践。具有Java核心技术、微服务、分布式、高并发等领域一线实战经验，并对新兴技术方向和各种开源框架有浓厚兴趣。公众号「服务端思维」的作者。
秦金卫（KimmKing），现任某公司高级技术总监/Apache Dubbo PPMC，阿里前架构师/某商业银行北京研发中心负责人。关注互联网、电商、金融、支付、区块链等领域，10多年研发管理和架构经验，对于中间件、SOA、微服务，以及各种开源技术非常热衷，活跃于 Dubbo、Fastjson、Mule、ActiveMQ等多个开源社区。个人博客http：//kimmking.github.io。
方志斌，现任某物联网公司高级研发工程师。目前专注于大型物联网平台架构的设计与开发工作。对于微服务、分布式、集群有一定的研究和实战经验。对Java领域的开源框架有浓厚的兴趣，喜欢深入分析、总结框架源码。SpringForAll社区核心成员，组织多次社区技术专题、问答等活动。
张逸，架构编码实践者，微服务架构设计者，领域驱动设计布道师，大数据平台架构师。著译作包括《软件设计精要与模式》《恰如其分的软件架构》《人件》等。个人微信公众号为「逸言」，个人博客：http：//zhangyi.xyz。
杜琪，网名阿杜，现任蚂蚁金服高级研发工程师，2015年6月毕业于南开大学，计算机系统结构硕士。毕业后开始接触分布式业务系统开发，曾在有赞负责用户中心基础服务，对分布式业务系统的稳定性、可靠性有丰富的经验。喜欢研究底层技术，喜欢研究疑难技术问题，例如JVM内存问题排查、GC调优，等等。有对外输出分享的习惯，是公众号javaadu的维护者。
殷琦，网名涤生，现任“美团点评”技术专家，2015年3月毕业于东华大学，软件工程硕士。2015年3月加入“美团点评”基础架构部，开始接触微服务架构，之后一直从事服务框架的研发工作，对微服务架构发展与演进有非常深刻的认识。个人比较喜欢研究并分享新技术，时刻关注并实践微服务架构最前沿的技术，如Service Mesh、Serverless 等。
肖冠宇，曾就职于小米、人民网等互联网公司，具有丰富的大数据一线实战经验，专注大数据处理技术及机器学习算法研究。著有《企业大数据处理：Spark、Druid、Flume与Kafka应用实践》《Python3快速入门与实战》等书籍。
由于本书写作匆忙，难免有错漏之处，后续可以通过勘误的方式不断优化，欢迎读者多提宝贵意见。程超2019年3月于北京CodingFly简介
CodingFly致力于打造一个深度服务于全球技术开发者的可信世界。利用区块链技术特性与优势重构信息化建设产业新生态。打造一个拥有全新的生产关系，无国界及地域限制的高效协同的链上技术开发者社区。
未来基于区块链的 CodingFly 是以社群方式运作，在这个社群中，当进行商业活动需要完成各种任务时，任何任务都可以通过智能合约，以悬赏的形式将工作内容拆分并发布，有能力有意愿的个人可以根据自己的情况，自由地选择接受任务，获取 Token，这个 Token不光是收入，同时也是对完成任务产生的数据所有权的确认，从而成为这个平台的一员，具有参与CodingFly治理的权利。
基于 CodingFly 的开发者做过的项目、作品、经验可以形成客观可信的记录，成为开发者的个人品牌资产。
CodingFly致力于塑造的世界是“个人+平台”而不是“公司+个人”，在CodingFly平台上，是自组织的，是基于社群的，没有员工的概念。读者服务
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
· 下载资源：本书如提供示例代码及资源文件，均可在 下载资源 处下载。
· 提交勘误：您对书中内容的修改意见可在 提交勘误 处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
· 交流互动：在页面下方 读者评论 处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http：//www.broadview.com.cn/36213第1章 微服务架构概述
随着架构设计的发展，微服务架构绝对是目前架构领域炙手可热的设计理念。自从微服务架构概念被提出以后，很多技术“大咖”也都给出了自己的诠释，业内很多知名公司研发团队也纷纷试水，使用微服务架构来指导自己的系统建设工作。目前的情况特别像十多年前面向服务架构（SOA）概念刚出现时的状况，经过技术圈无数人长达几年的讨论和发展，SOA架构的内涵和外延最终成为我们目前了解和看到的样子。本书根据目前国内外的各种技术思想，以及各位作者自身多年的架构经验，以及近年对微服务架构的实践总结，完整呈现了微服务架构的发展历程、设计特点、架构实践，以及高可用、一致性、数据、部署、监控等各方面的内容。
本章先回顾一下软件架构（Software Architecture）的发展历程，了解微服务架构（MicroServices Architecture，简称MSA）产生和发展的来龙去脉。1.1 什么是架构
计算机科学和程序设计的飞速发展，使得软件设计应用在从航空航天到日常生活的方方面面。个人开发一段小程序的做法早就过时，大范围协作的工程化时代随即到来。随着大范围协作带来的效率问题和软件复杂度的爆炸式增长，管理和技术方面的各种不确定性也爆发性增加，导致软件开发的质量无法得到有效保证，开发周期和成本无法得到有效控制。人们一直在寻求这些问题的解决方法。然而Fred Brooks在1975年出版的软件工程圣经《人月神话》中写道，没有（能解决所有问题的）银弹（There is no silver bullet）。自此，人们发展了项目研发过程管理来控制管理活动的不确定性，同时发展了软件架构设计方法来控制技术方面的不确定性，进而在实践中不断地总结和改进，用于有效指导软件的开发过程，最大程度地保障软件的质量、开发周期和成本。
自软件工程产生以来，架构设计和过程管理一直是软件领域 DNA 的双螺旋。前者从科学技术领域出发来解决软件创造中的工程技术问题，后者从人类的管理活动出发发展了软件工程的组织管理方式。两者都是为了解决大规模软件开发过程中的各种问题而出现的。
架构的定义
架构（Architecture）一词源于建筑领域，其本身就是建筑的意思，也有体系结构的意思。维基百科英文版里对Architecture的解释是：规划、设计和建造建筑物的过程及产物。鉴于软件工程与建筑工程一样是一项系统的工程性工作，在引入计算机领域后，软件架构就成为描述软件规划设计技术的专有名词。特别地，软件架构师一词在英文里和建筑师也是同一个词（Architect）。
1972年图灵奖获得者、荷兰计算机科学家Edsger Wybe Dijkstra（就是大名鼎鼎的Dijkstra最短路径算法的发明者）早在二十世纪六十年代就已经涉及软件架构这个概念了。到了二十世纪九十年代，Rational Software Corporation和Microsoft、卡内基梅隆大学和加州大学埃尔文分校在这个领域做了很多研究和实践，提出了软件架构中的很多概念。
维基百科里对软件架构的定义：
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构师定义和设计软件的模块化、模块之间的交互、用户界面风格、对外接口方法、创新的设计特性，以及高层事物的对象操作、逻辑和流程。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或对象。在面向对象领域中，组件之间的连接通常用接口来实现。
Kruchten认为：
架构是对软件系统组织、结构部分和系统包含接口的选择，满足功能和性能需求的一系列架构元素的集合。软件架构设计与软件高层次结构的实现能够抽象、分解、组合等。
Bass等人认为：
系统或计算系统的软件架构是包含软件部分、外部可见特性部分，以及它们之间关系的系统结构。
McGovern则认为：
软件架构或系统由组成系统的结构的相互作用和软件结构的重要设计决定组成。设计决定应成功实现所期望支持的质量。设计决定为系统开发、支持和维护提供概念上的基础。
比较公认的软件架构定义是在2000年的ANSI/IEEE 1471标准《软件增强系统的体系结构描述推荐实施规程（Recommended Practice for Architectural Description for Software-Intensive Systems Description）》、2011年的ISO/IEC/IEEE 42010标准《系统和软件工程—架构描述（Systems and software engineering—Architecture description）》中定义的。（1）架构过程：在系统整个生命周期中构思、定义、表达、记录、交流，验证合适实现，维护和改进架构的过程，也就是设计过程。（2）架构：一个系统体现在其环境中的元素、关系的基本概念或属性，以及其设计和进化原则。（3）架构描述：表达一个架构的工作产出物（通常指的是各种架构图和设计文档）。（4）架构视图：通过系统的某些关注点的视角，表达一个系统的工作产出物（例如部署视图、开发视图等）。（5）系统：包含一个或多个进程，硬件、软件、工具与可以满足需求的人的集合。（6）环境：决定开发、操作、策略和其他影响系统的设置和条件。
在 UML 中，架构被认为是系统的组织结构和相关行为。一个系统的架构可看作通过接口互联部分的关系，以及它们之间的相互作用。通过接口相互作用的部分包括类、组件和子系统。这样就可以通过UML的各种架构图来描述这些对象和关系，从而清楚表达一个系统的架构。
总结：软件架构是一个用于指导系统实现的草图。这个草图越详细，对系统实现的指导意义就越重要，且贯穿于软件的整个生命周期。在建筑领域，大楼尚未建造前，就已经存在于建筑师的脑海里。同样地，开始编写第一行代码之前，系统就已经存在于软件架构师的心里。那么怎样把架构草图表达出来呢？我们一般都是采用架构图和设计文档的形式。如果我们进一步追问，使用哪些方面的架构图和设计文档就能把架构草图表达清楚呢？草图里包含哪些具体的要素和对象呢？围绕着不同的具体操作手段，就产生了不同的架构方法论，本章后续的内容会逐步介绍。1.2 几个相关概念
1.1.1节阐述了什么是软件架构，我们经常说的软件领域名词还有模式、类库、框架、模块、组件、服务和平台等，它们跟架构有什么关联呢？下面会逐一阐述。
1.模式（Pattern）
模式是建筑大师Christopher Alexander于二十世纪七十年代提出的概念，关于八十年代中期由Ward Cunningham和Kent Beck将其思想引入软件领域。Christopher Alexander将模式分为三个部分：一是模式产生的上下文环境（Context）；二是动机（System of Forces），也就是预期目标或要解决的问题；三是解决方案（Solution），指平衡各动机或要解决问题的一个处理手段。他提出了一个软件领域广为接受的定义：模式是表示上下文环境、动机、解决方案三方面关系的一个规则。每个模式描述了在特定上下文环境里不断重复发生的某一类问题的解决方案。
UML中给出的解释更通俗易懂：模式是对于普遍问题的普遍解决方案。我们可以把一类问题的共性抽象出来，这样就可以用同样的处理办法去解决这些问题，从而形成模式。所以模式是一些经验的总结。从这个角度来说，软件架构作为一种软件设计过程的指导准则，也是一些经验的积累和问题的抽象，同样可以看作一种模式。更一般地，根据处理问题所在领域的粒度不同，我们可以把模式分为架构模式（Architectural Pattern）、设计模式（Design Pattern）和实现模式（Implementation Pattern）三个层次。
· 架构模式是最高层次的模式，在软件过程里描述系统的基础结构、子系统划分，确定职责和边界，以及相互作用关系。一种具体的架构模式可以包含一系列的设计模式。
· 设计模式是用来处理程序设计里具体场景下的问题的办法，比如GOF（Gang of Four，指的是Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides这四位作者）在《设计模式：可复用面向对象软件的基础（ Design Patterns：Elements of Reusable Object-Oriented Software）》一书里提及的23个基本设计模式（工厂模式、单例模式、代理模式、观察者模式等），Gregor Hohpe和Bobby Woolf在《企业集成模式：设计、构建和部署消息传递解决方案（Enterprise Integration Patterns：Designing，Building，and Deploying Messaging Solutions）》里提及的各种集成设计模式（通道模式、消息模式、路由模式、转换模式、端点模式等）。
· 实现模式是最低层次的具体问题的处理办法，例如编码规范、命名规则等。
2.类库（Library）
类库是一组可复用的功能或工具的集合，应用系统通过调用它们从而达到复用功能的目的。例如，Windows应用开发里的各种静态或动态链接库（DLL）文件，Java开发项目里依赖的或Maven中央库里的各种jar包（比如Apache commons-io、Httpclient，Log4j等），都是类库。
类库根据其所在的语言或平台环境的不同，可以是编译后的二进制执行码或中间码形式（DLL 或 jar），也可以是源代码（PHP、Node.js 里的类库）。类库的调用关系一般在开发期引入目标应用的项目，运行期执行实际调用。
3.框架（Framework）
框架是基于一组类库或工具，在特定领域里根据一定规则组合成的开放性的应用骨架，比如SSM/SSH框架，更大范围来说，.NET Framework、JDK都算框架。框架具有如下特性：（1）支撑性+扩展性：框架不解决具体的业务功能问题，我们可以在框架的基础上添加各种具体的业务功能、定制特性，从而形成具体的业务应用系统。（2）聚合性+约束性：框架是多种技术点按照一定规则形成的聚合体。我们采用某种框架也就意味着做出了技术选型的取舍。在很多种可能的技术组合里确定了一种具体的实现方式，后续的其他工作都会从这些技术出发，也需要遵循这些规则，所以框架本身影响了研发过程里的方方面面。
在一个具体的框架之上添加一些基本或可复用的功能，这时就得到一个介于框架和应用之间的结构，一般称它为脚手架（Scaffold），可以用来快速实现类似的项目。
关于框架与架构的关系，Vasyl Boroviak在stackoverflow网站上提出过一个形象的比喻，如图1-1所示。图1-1
从这个意义上来看，框架是一些具体的事物，而架构更抽象。所以一个名叫 Art 的stackoverflow网友说：架构是理论，框架是实现。
4.模块（Module）
模块是业务或系统按照特定维度的一种切分，也可以看作各种功能按照某种分类聚合的一种形式。例如一个电商系统，一方面，可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块和售后模块等。另一方面，我们也可以说用户模块聚合了用户注册、用户验证等业务功能。这样，我们在设计和开发的过程中，就可以按照模块的维度去组织，比如每个模块新建一个源码的子项目（subproject）、打包成一个单独的 jar 包，也可以放到一个项目里用不同的package名称来区分等。模块一般是系统在较大粒度上的解耦切分，仅次于系统或子系统的级别。
5.组件（Component）
组件是一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接作为业务系统的组成部分，粒度一般小于模块，也是一种功能的聚合形式，比如日志组件、权限组件等。根据组件的形式、行为和用途的不同，我们又可以延伸出一些概念。
· 构件（Composite）：具有层次组合关系的多个组件组合形成的复杂组件形式。比如Eclipse RCP里一个Window左边嵌套一个TreeView组件、右边添加一个GridView组件，这样就形成了一个Composite构件。
· 部件（Widget）：部件主要是有UI界面的构件，比如Windows 7或Mac系统自带的桌面天气小部件等。
· 插件（Plugin）：系统运行期间可以即插即用、随时停用或卸载的组件，一般有确定的生命周期，比如Google Atom编辑器的各种插件、OSGi中的bundle、Eclipse插件（本质上也是OSGi的bundle）等。
6.服务（Service）
成立于1993年的结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，简称OASIS，XML和WebService规范就是这个组织提出的）把服务定义为：
一种允许访问一个或多个功能的机制，其中访问需要使用规定的接口，并且与服务描述中指定的约束和策略一致。
服务是一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如WebService或REST 等），服务描述里应该包括约束和策略（比如参数、返回值，使用什么通信协议和数据格式等）。本章的面向服务架构（SOA）会详细阐述服务的相关内容。
7.平台（Platform）
一般来说，平台是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多的服务、接口、规范、标准、功能、工具等。例如 J2EE 平台，包含企业级应用开发里的各种基于Java语言和JVM虚拟机运行时的技术能力。
知乎社区编程领域优秀问题回答者ze ran说：
库是工具箱。
框架是一套通用的解决方案。
架构是高度抽象的需求，是系统中的不变量。
平台是所有可能做的事的集合。
事实上，服务、平台、架构这几个概念这几年已经被泛化了，什么地方都可以滥用这几个词，随便一个系统都可以说自己是大数据平台、XX业务平台、XXX服务化架构。
大概在2009年的时候，在一个SOA的技术交流群，一个程序员跟大家分享自己的项目是服务化的、SOA架构的。大家很好奇，请他详细讲解自己的系统是如何做到服务化的。这位程序员就给大家发了一个 Eclipse 里项目结构的截图，项目里的每一个目录或包名都是以 service结尾的。他就跟大家解释说，这就是我们项目的面向服务架构，我们落地了SOA架构。大家说着同一个技术名词，理解和认识却完全不一样，这就贻笑大方了。
10年过去了，我们将在后续章节里分析这些年来架构技术的发展情况，同时可以了解自己所在研发团队和系统使用的架构处于何种阶段。1.3 从软件的生命周期看架构设计
一个典型的软件生命周期如图1-2所示。图1-2
可以把这些阶段概括为3个大的周期：设计期（包括立项、计划、技术选型与方案等）、实现期（包括开发、测试、发布、实施等）、运行期（或维护期，包括修复 bug、新增功能、多版本维护等）。
1.设计期
在设计期，软件作为一个成品还不存在，所以我们可以称之为概念形态。此时架构师、产品经理或需求分析师等人员利用自己的经验和能力，对系统的业务需求进行分析、拆解、抽象，对系统的非功能性需求进行分析，形成业务文档和技术文档，以及技术验证代码等。这个阶段，架构设计工作是重中之重，其中包括：
· 系统拆分，如何把系统拆解为不同的子系统、模块、业务单元；
· 技术选型，使用什么样的基础技术框架或脚手架；
· 技术验证，确定核心技术难点如何解决，检验能否满足期望指标；
· 接口规范，系统内部的不同部分以何种形式确定接口契约和数据通信方式；· 集成方式，系统与外部其他业务系统如何进行集成；
· 技术规范，如何规范开发、测试、部署和运维的技术标准性；
· 部署方案，系统如何进行物理部署，需要多少台机器、什么配置，对网络有什么要求；
· 运维方案，系统如何进行技术性运维，如何实现日常监控、预警报警；
……
这个阶段总结一下就是：需求导向，架构先行（包括业务架构和技术架构）。很多项目因为前期的设计阶段考虑得不够充分，导致在开发和运行期出现大量问题。
2.实现期
这个阶段主要是编码与测试，为部署上线做好准备，是软件从设计到最终的生产系统的过程，我们可以称之为代码形态。此阶段需要考虑的技术类工作如下：
· 确保各项技术规范和技术指标的执行落地，保障高质量的代码；
· 指导研发人员和解决各类技术问题，提升研发团队效率；
· 制定测试的技术性方案和基准，包括自动化、性能、安全等方面；
· 配合准备部署环境，运维实施方案落地等；
实现期的主要任务是大量软件工程师根据设计期的设计进行编码。大量的技术人员，大家背景不同，知识储备不同，编程水平和习惯不同，努力程度不同。如何让所有工程师既能够按数量保障项目进度，又能够按质量保障软件品质呢？秘诀就在于：技术标准的精确统一，系统部件的良好拆分，此外最好有适合于此类项目的脚手架，随时能解决各位技术难点问题的“救火队”。系统部件的良好拆分，保障了任务可以拆散成一个个的小单元，分发给不同的开发者。技术标准的精确统一，可以实现不同个体的产出物最大程度的一致性。
这个时期因为业务调整或技术问题，可能会对架构设计的一些细节进行小范围的调整，以适应实际项目的建设需要。在这个过程中，同时需要根据实际变化，对现有的设计文档进行同步调整，以便精确地描述系统的状态及变化。
3.运行期
这个阶段系统上线、验收通过，已经初步稳定，然后开始进入维护阶段，成为设计期架构设计草图的一个可用实例，我们可以称之为实例形态。此时需要考虑：
· 发布上线相关基础性工作，包括是否使用持续集成（CI）、自动化发布等技术；
· 运维基础性工作，自动化运维、监控等相关技术；
特别是发布与运维工作，一般要作为整个研发团队的通用性基础设施来考虑。不同的业务线或系统，可以复用一套基础设施来服务于生产环境。进入维护期后，软件系统日常通过内外部用户反馈的问题和改进意见，不时需要修改代码发布补丁版本，或者调整配置以满足用户需要。经过较长一段时间，业务模式和内外部环境发生了比较大的变化后，系统简单的补丁维护可能已无法满足用户需求，需要大范围地添加新功能和修改旧功能的逻辑流程。此时就可以成立专门的团队，重复上面的步骤，基于现有系统重新做一些改造性的设计重构（设计期），再编码实现（实现期），最终发布一个较大的版本（运行期）。
在软件的整个生命周期里，架构师（或架构组）是一个项目或产品线的技术负责人。再大一点的组织，比如公司或研发中心级别层面也许还有架构部。架构师、架构组、架构部在不同层面对自己工作涉及的所有技术问题负责。其实上面罗列的这些工作汇总一下，再加上技术规划与执行落地、技术人才的选拔与培养等，可以作为项目组架构师或研发团队架构组的工作职责。1.4 架构的形式与特点
1.架构以文档和代码呈现
我们一般说的架构既包括架构的设计过程，又包括设计的产出物，可以是各类设计文档、设计图，也可以是一些技术验证代码、Demo或其他相关程序。文档的目的在于准确记录我们的思维产物，在软件尚未实现时，作为指导蓝图，尽量精确地描述清楚软件。在软件的实现过程中，可能随着我们的深入研究，根据具体情况对文档做出局部的调整和修改。在软件已经实现以后，部署运行的软件实例和代码只能说明软件目前是什么状态，却无法告诉我们这个软件系统是如何从开始设计，慢慢变成现在看到的样子的，这个思维的过程和中间做出的很多决策的信息丢失了。一个软件系统的长期稳定发展，必然需要一个可靠的、随着软件本身的维护不断同步更新的文档作为每次变更的出发点。这样我们可以随时沿着架构相关的文档逆流而上，了解这个软件系统从整体到具体的设计思路。同时，文档作为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司IT资产的有机组成部分。
其中一个架构图的例子如图1-3所示。
文档是设计的载体，代码是系统功能实现的载体，技术和业务最终都有很大一部分体现在代码里（技术的另外一部分是部署运维，即
试读结束[说明：试读内容隐藏了图片]