作者：郑天民
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
系统架构设计试读：
前言
软件行业技术开发从业人员众多，但具备若干年开发经验的普通开发人员往往面临个人发展的瓶颈，即如何从普通开发人员转型成高层次的系统架构师和技术管理人员。想成为一名架构师，应当具备全面的知识体系，需要进行系统的学习和实践。很多开发人员有往架构师转型的强烈意愿，但苦于找不到好的方法和路径。本书把“程序员向架构师转型”作为切入点，提供架构师所需的各方面技能和相应的学习方法，包含针对转型的一些思路、方法、工程实践及可能会碰到的问题和解决方法。本书从架构师的定位及如何成为一名架构师的角度出发，除了技术和设计之外，还会介绍各项系统工程方法论和软能力，旨在为广大开发人员提供一套系统的、全面的转型指南。
本书从“向架构师转型”的角度出发，结合作者在传统及互联网行业多年的技术与管理工作经历展开论述，结合方法论和工程实践，具有较强的针对性和适用性。架构师是一种综合性强的工种。本书整体上是“技术”结合“过程”的行文思路，具备一定深度的同时也涉及更广的知识领域和体系，满足读者往架构师转型过程中的各种技能需求。同时，本书在介绍技术及过程管理的内容时，采用“思路→方法论→工程实践”的三段式模型，不光告诉读者可以怎么做，更重要的是提供了对问题的分析及解决思路和方法论，并辅以相应的工程实践和案例分析。对架构师而言，具体的技术和工具并不是重点，解决问题的思路和方法论才是本质。本书会在这些方面提供一定的指导并进行总结。
全书共分为4个篇幅，共计9章内容，分别从不同的领域对架构师转型所需要的各项技能展开讨论。
1.程序员向架构师转型概述篇：剖析架构师角色，提供架构师的视图和视角及程序员向架构师成功转型的思路。
2.系统架构设计知识体系篇：介绍软件架构体系结构、领域驱动设计、分布式系统架构设计、构架实现技术体系等架构师所应具备的主要技术体系内容。
3.软件架构系统工程篇：介绍软件工程学、敏捷方法与实践、软件交付模型等架构师所应具备的系统方法论和相关工程实践。
4.架构师软能力篇：包括架构师与外部环境、自身团队和转型所需的意识形态。
本书面向立志于转型成为架构师的后端服务开发人员，读者不需要有很深的技术水平，也不限于特定的开发语言，但熟悉Java EE常见技术并掌握一定系统设计基本概念有助于更好地理解书中的内容。通过本书的系统学习，读者将在普通开发人员的基础上向前跨出一大步，在思想、方法论、实践能力和综合素质等各个方面往一名合格的架构师方向发展，为后续的工作和学习铺平道路。
在本书的撰写过程中，感谢我的家人特别是我的妻子章兰婷女士在我占用大量晚上和周末陪家人时间进行写作的情况下，能够给予极大的支持和理解。感谢以往及现在公司的同事们，身处在业界领先的公司和团队中，让我得到很多学习和成长的机会。没有平时大家的帮助，不可能有这本书的诞生。最后，要特别感谢北风网的童金浩和罗思捷老师，提供了北风网（http://www.ibeifeng.com）这样优秀的互联网教育平台完成本书配套视频的录制和发布。
由于时间仓促，作者水平和经验有限，书中难免有欠妥和错误之处，恳请读者批评指正。可关注微信公众号“程序员向架构师转型”或扫描以下二维码与本书作者进行联系。郑天民2016年12月于杭州钱江世纪城第一篇程序员向架构师转型概述本篇内容
本篇从架构设计的基本概念出发，阐述架构设计的理论体系。接着引出架构师角色，从架构师的活动、分类、技能和职责等角度对架构师的角色做了深度剖析，并对普通开发人员和架构师的区别进行了全面比较。成为一名架构师前，需要明确架构师所需掌握的视图和视角。这些视图和视角是架构师手上的武器。最后本章对“程序员如何向架构师成功转型”这个话题进行展开，提出转型成功所需的三段式模型，并提供了转型所需的思维导图。
本篇只有一章，作为开篇总领全书后续章节。思维导图第1章 程序员向架构师转型
随着近年来信息化产业的高速发展，一大批由国人自主研发的计算机软件系统，尤其是以电子商务、O2O、移动医疗、在线教育等为代表的互联网和“互联网+”应用已经深刻影响着我们的日常生活模式。面对新的时代潮流，无论对于传统行业还是互联网行业，开发具有功能强大且用户体验好的桌面端和无线移动端应用已经成为众多软件从业人员的目标和要求。然而，分析和设计一个软件系统及管理其研发过程并不是每一个软件行业从业人员都能做的事情，需要具备专业的知识、丰富的实践经验及良好的个人综合能力。我们把具备以上能力的人才称之为软件架构师。
中国目前每年有几十万的软件开发人才缺口，其中具备系统架构设计和实现能力的人才更是紧缺。对于一名软件开发人员而言，成为一名合格乃至优秀的架构师是自身奋斗的一个方向。同时，对于一名具备多年行业从业经验的开发人员，如果目前还处在普通的开发人员行列，还不具备相应的意识形态和专业能力去从事系统架构设计和实现相关工作的话，那成为一名架构师事实上也是自身发展所不得不面临的一个瓶颈。如何打破这个瓶颈，如何从普通的程序员转型成为一名架构师，对于广大开发人员而言都可能是值得思考的问题。
本章首先介绍了系统架构设计的基本概念，然后从架构师这一特定角色出发，全面剖析架构师与普通开发人员的区别，以及对于一名架构师而言应该具备的视图和视角。最后，围绕“转型”问题，提出从程序员到架构师成功转变所应具备的关键因素。1.1 架构设计基本概念
当下，业务需求层出不穷、技术发展日新月异、团队规模快速扩张，因此，软件系统复杂度及系统共性和特殊性问题在很大程度上决定了软件开发的成败。而软件架构设计（Software Architecture Design）的目的就是对系统进行高度抽象，通过一系列设计原则在最大程度上降低系统复杂度，解决系统中存在的各种共性和特殊性问题。在深入探讨架构设计过程和架构师角色之前，我们先来理解架构的基本含义。1.1.1 架构的基本定义
我们想要成为一名架构师，有如下两个问题首先需要进行明确。
●软件架构是什么？
●软件架构设计是怎么样一种工作内容？
围绕着这两个问题，业界有一些通用的说法，这些说法形成了具有代表性的两大理论体系，分别是架构组成理论和架构决策理论。1.架构组成理论
国际标准化组织（International Orgranization for Standardization，ISO）系统和软件工程标准认为，系统的架构是一系列基本概念或者系统在其环境中表现出来的属性，体现在它的元素、关系及设计和发展的原则中。根据ISO给出的这一架构定义，系统架构包括系统元素、基本系统属性、设计和发展原则3个主要方面。（1）系统元素
架构的系统元素包括模块、组件、接口、子系统等日常开发中的内容。系统元素之间是有关系的，元素加上它们之间的关系就构成了基本的系统结构。通常，架构师感兴趣的结构类型包括静态结构和动态结构。所谓静态结构体现在设计时，描述系统内部设计时元素及其组合方式；而动态结构则关注运行时的元素及其交互方式。（2）基本系统属性
架构的基本系统属性一方面包含功能属性，用于说明系统行为属性，回答系统能做什么这一问题，如系统的输入、输出模型。另一方面，系统也关注质量属性，即外部可见非功能性属性，如系统的性能、安全性等属性。（3）设计和发展原则
架构的设计和发展原则应该能够可度量、可测试和可跟踪，常见的原则如用户操作响应时间在1s之内、用户信息需要进行安全性处理、系统可以快速集成第三方服务等。同时，对于架构的设计和发展，每个团队及架构师都可以根据需要制定适合于当前架构发展需要的自定义原则。
组成派的架构设计往往首先关注系统的主要构成部分及它们相互之间的关系，然后进一步挖掘每个构成部分的细节，以便确定模块、组件、接口等元素，并确保这些元素满足既定的架构设计原则。Web开发中常见的MVC（Model View Controller，模型—视图—控制器）模式实际上就是架构组成理论在架构风格上的体现，通过Model、View和Controller等3种基本元素及它们之间的不同交互方式构成了系统的基本架构，如图1-1所示。图1-1 MVC模式的两种交互方式2.架构决策理论
架构决策理论的典型倡导者是RUP（Rational Unified Process，统一软件过程）。该理论关注架构实践的主体—人，以人的决策为描述对象。架构决策不仅包括软件系统的组织、元素、子系统和架构风格等，还包括众多非功能性需求的决策。当架构设计过程无法顺利进行，如碰到模块如何划分、模块之间交互方式是什么、开发技术如何选型、如何适应可能发生的变化等常见问题时，通过架构师团队根据场景和问题作出相应的决策。不断决策的过程就是问题得到不断解决、架构得到不断发展的过程。通过一系列的决策最终形成完整的系统架构。
决策类的架构设计过程往往可以从系统切分出发，如把系统分成客户端和服务器端两大部分，然后基于服务器端，可以在拆分成服务适配层、业务逻辑层和数据访问层，而业务逻辑层再可以分成多个模块，如图1-2所示。每一个切分的过程实际上就是一个决策的过程，通过合理而有效的决策促进系统架构由高层次到较低层次再到实现层次的不断演进。图1-2 架构决策示例
以上两个派别的理论体系也只是对架构定义问题的一种诠释，业界还有很多相关的说法，很难给出一个标准化的答案。每个架构师基于自身的意识形态和经历也可能会有自己的理解，通常开发人员从日常的开发过程中提炼出对架构设计的理解，被称之为架构演进理论。1.1.2 架构演进理论
在过去软件开发过程发展的很长一段时间内，软件架构表现为一种集中式的单块（Monolithic）模式，即先对系统进行分层，然后通过单个进程进行部署和维护。典型的分层体系包括界面交互层、业务逻辑层和数据访问层。直至今日，这种单块模式在部分系统构建过程中仍然是最基本的架构模式。
随着业务功能的不断发展及性能、数据存储等系统瓶颈问题的出现，单块模块逐渐不适合系统的维护和扩展。这时，分布式架构应运而生。通过把系统业务进行服务化及完善服务治理功能，系统架构就可以如同搭建积木一样构建成高度可集成、高内聚松耦合的业务系统，图1-3所示的系统主体由Frontend-Service（前端服务）和Core-Service（核心服务）两层服务化构成，为Web层提供网关和核心业务服务。图1-3 分布式服务模式
服务化架构为系统提供了扩展性和伸缩性，然而随着系统用户体量的增加及分布式系统固有的网络通信机制，性能问题在业务关键链路逐渐成为系统运行的瓶颈。解决性能问题的切入点有很多，一方面可以从硬件设备和软件服务器入手，但对系统架构而言，更多的场合需要我们分析系统实现方案，并使用以缓存为代表的架构设计手段重构业务关键链路，图1-4即为在Frontend-Service和Core-Service两层服务中分别添加分布式缓存（Distributed Cache）之后所得到的系统部署图。图1-4 分布式缓存架构
缓存能够提升性能，但不能解耦系统。当系统中分布式服务数量和种类增多，而这些服务又分别属于不同业务层次时，如何合理地管理这些服务之间的调用关系，进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性。在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义及技术平台的差异性等问题。这些问题为开展快速架构重构和扩展、进行高效分布式团队协作带来了挑战。以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时，消息中间件（Middleware）能显著降低系统的耦合程度，如图1-5所示，在Frontend-Service和Other-Service（其他服务）中添加了消息传递中间件，确保两个服务在并不需要意识到对方存在的前提下进行数据的有效传输。图1-5 消息中间件架构
试想这样一种场景，我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理，而这些外部系统分别部署在其他供应商或客户环境，并且每个系统都可能基于完全不同的技术平台和体系构建，随着业务发展需求，这些外部需求还需要实现动态的注册和注销。对系统架构设计而言，一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作，另一方面，我们又不希望我们的系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值，因为外部系统不在控制范围之内，我们对其内部实现原理一无所知。如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成，企业服务总线（Enterprise Service Bus，ESB）提供了相应的解决方案。通过在核心业务服务中引入ESB及对应的路由、过滤、转换、端点等系统集成模式，即可屏蔽由于技术差异性导致的各种系统集成问题，并动态管理ESB上的第三方服务。图1-6中的ESB为内部的Core-Service整合外部的Thirdparty-Service1和Thirdparty-Service2提供了集成平台。图1-6 企业服务总线架构
随着大数据时代的到来，许多业务系统也面临着对庞大业务数据进行管理和利用的难题。近年来，以Hadoop生态圈为代表的大数据处理平台，以及以Lucene为内核的多种垂直化搜索引擎（Search Engine）系统，为业务发展提供了高效的批量数据处理和数据搜索功能。在系统架构设计维度，我们也可以引入如Spring Batch、Spring Data等轻量级的批处理（Batch Job）和数据访问框架，以便与基于Spring的核心系统构建框架进行无缝整合，如图1-7所示。图1-7 搜索引擎和批量数据处理架构
上述系统架构演进过程在现有的互联网应用中具有一定的代表性，很多APP（Application，应用程序）后台就是从一个简单的单块模式开始，当面临系统架构设计问题时，通过引入各种技术系统逐步完善架构，直至具备庞大体量的大型集群系统。在这个系统架构演进过程中，我们再来回答“什么是系统架构设计”这个问题时，我们就可以认为系统架构设计是在系统开发演化过程中，解决一系列问题的方法论和工程实践。
方法论和工程实践包含了系统构成的各种结构化元素，包含了系统交互的各种接口和相互协作方式，包含了通用的指导性架构风格。更为重要的是，通过引入方法论和工程实践进行系统架构演进是一个“原型→发现/改进→再发现/再改进”的过程。这显然已经不是一个纯粹的技术问题，而是一项涉及多个软件开发维度的系统工程。1.1.3 架构设计与系统工程
架构设计是一项系统工程，而系统工程本质上是一个多学科工程，涉及软件开发的技术和管理两方面。一般而言，系统工程可以简单描述为一种人、工具、流程等基本构成元素的组合，图1-8即是对架构设计系统工程的一种描述方法。图1-8 架构设计系统工程
我们通过上图把架构设计通过系统工程的方法展开，可以清晰地看到以下几点核心思维。1.人
架构设计中的人除了架构师本身主要指的是各种干系人（Stakeholder）。所谓干系人，就是架构所需要满足的各种业务方、客户、市场、项目、产品等相关人员。这些干系人代表着功能需求的来源，同时拥有对系统架构是否成功的判断权利。架构设计本质是满足业务需求，业务架构驱动着技术架构，而不是反其道而行。系统工程的第一点核心思路就是我们从事任何架构设计相关的工作都是为了满足干系人的需求。2.事
架构设计中的事主要包括描述架构和展示架构。架构描述代表着使用特定的工具、特定的流程和特定的视图视角创建、记录和维护架构。架构展示则把描述出来的架构在合适的时机和场合展示给相关干系人供其参考和判断。无论是架构描述还是架构展示都不是一步能够到位的，所以系统工程的第二个核心思路就是我们要站在过程管理的思维模式上去看待架构设计这件事情：架构设计本身也是一个过程，过程就需要通过计划、实施、监控、管理等方法确保其执行，并通过持续改进实现过程的高效性和正确性。3.物
架构设计相关系统工程的物指的就是所设计的架构及对应的架构描述。架构描述并不只是架构师的个人成果，而是架构师及相关干系人共同确认的成果，用于构建系统，以满足业务需求。系统工程的第三个核心思路就是需要提供架构设计产物的可见性，同时确保具备较高设计质量，使其能够接受来自内部和外部的评审和验证。
综上所述，架构设计就是以干系人提出的业务需求为源头、以技术管理和过程改进体系为工作流程、以质量为重心的一项系统工程。在系统工程中，业务需求需要进行分析和抽象、过程需要进行管理和改进、设计质量需要进行保障，完成包含这些活动在内的整个系统架构设计工作的角色就是架构师。1.2 剖析架构师角色
架构设计被认为是从问题领域到解决方案的一种桥梁，如图1-9所示。从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接交集，连接着两个软件开发的核心领域。图1-9 架构设计的桥梁作用
架构师是架构设计的执行者，架构设计的桥梁作用给架构师带来了挑战，意味着架构师需要同时具备处理两个核心领域的能力，即架构师需要能够从问题领域出发推导出满足业务需求的架构体系，同时又能够从实现方法入手设计出能够满足业务架构需求的技术架构体系，最终实现业务架构和技术架构的统一。1.2.1 架构师角色1.架构师的活动与系统工程
架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下4项工作。（1）识别干系人并让他们参与进来
干系人是业务需求的源头，识别正确的干系人能够确保业务需求的正确性，让干系人参与能够确保业务需求的实时性和有效控制需求变更。（2）理解和记录系统功能和非功能相关的关注点
通过需求分析，架构师梳理并抽象系统的各项功能性和非功能性需求，并对这些需求进行系统建模。（3）创建并拥有应对这些关注点的架构定义
对功能性和非功能性需求，从扩展性（Extensibility）、性能（Performance）、可用性（Availability）、安全性（Security）、伸缩性（Scalability）等架构设计的基本要素出发定义架构。（4）在把架构实现为具体系统的过程中起主要作用
推动架构设计活动按照项目和产品计划有序进行，参与需求、设计评审等各种技术评审过程，并管理系统设计和开发团队的日常工作。
就一个完整的系统开发生命周期而言，架构设计活动有其时效性。图1-10体现了传统瀑布（Waterfall）模型下的系统开发生命周期与架构师参与情况。从图中可以看出在由需求分析和系统建模所构成的系统初始阶段，以及由服务集成和产品接受所构成的最后交付阶段，架构师会较多地参与到系统建设过程中去。具体参与程度取决于系统本身的特征及生命周期模型。
对于类似Scrum的敏捷开发模型，如果把一个个迭代看成是小型的Water-Scrum-Fall模型的话，架构师参与程度实际上也与图1-10所示的结果相类似，即重点参与迭代计划阶段和迭代演示回顾阶段。图1-10 系统开发生命周期与架构师参与情况
从系统工程维度，架构师根据干系人的业务需求捕获系统功能和非功能相关的关注点，并创建架构描述。架构师对架构描述这一架构设计产物具有拥有权，意味着架构师有权力更有责任维护架构描述并管理其实时性和有效性。同时，架构设计表现在系统过程中是一系列架构定义过程。架构过程的正确性决定着架构结果的正确性，架构师需要跟踪并验证架构定义过程的时机、参与者、技术评审和各项阶段性成果。添加了架构师角色及其职责的系统工程如图1-11所示。图1-11 架构师与系统工程2.架构师的分类
基于以上关于架构师的工作内容、参与程度和系统工程的分析，可以看到架构师根据其作用、职责和对系统关注层次的不同，可以分成很多类型。狭义上的架构师往往偏重于技术架构设计。但从广义上讲，业界对架构师的划分有一定的体系，表现在以下3个方面。（1）根据作用
根据所发挥的核心作用，可以把架构师划分成设计型、救火型、布道型、极客型等类型。相较于传统意义上的设计型架构师，救火型、布道型、极客型等类型的架构师更加偏重于执行某一项特定的架构任务，并不一定会完整参与系统开发生命周期，更不一定会从系统工程的角度去看问题。（2）根据职责
产品型、基础设施型和应用型等架构师是从其所处的业务和职责出发进行分类的结果。产品型架构师偏重于进行业务架构设计，往往在系统开发前期会重点参与；基础设施型架构师偏重于进行技术基础框架设计，一般采用独立于系统开发生命周期的特有开发模式；常见的系统架构师指的是应用型架构师，正如前文所述，负责将问题领域进行建模并转变成解决方案。（3）根据关注层次
架构师关注的层次有很多，不同的架构师关注的层次会有所不同，包括但不限于功能、非功能、团队组织和管理、产品运营等方面。
本书所阐述的架构师角色，从作用上讲指的是设计型架构师，从职责上讲偏重于应用开发，并关注于功能、非功能、团队组织和管理等层次。3.架构师的技能和职责
作为一名合格的架构师，完备的技术领域知识是必备的技能，包括我们在1.1.2节架构演进理论中提到过的分布式系统、缓存、消息中间件、企业服务总线、搜索引擎和批量数据处理等各种目前业务主流的技术体系，也包括软件架构体系结构中所蕴含的架构风格、架构模式和架构模型思想。但针对应用设计型架构师，所需的技能不仅仅限于了解和掌握技术体系，也需要从另外两个层面进行技能拓展。（1）业务领域知识
在应用程序开发过程中，业务架构驱动技术架构现象非常普遍。提升业务领域知识和提升技术领域知识一样，都对架构设计有直接影响。从这个角度讲，架构师应该具备跨领域的技能。（2）软技能
无论是传统型软件还是互联网应用，当前的开发模式已不再崇尚靠能力出众的个人来决定系统的产出，而是要靠团队。架构设计同样面临着项目计划同步、第三方服务集成、外部团队协作等团队性活动需求，很多场景下，架构师需要与内部团队、外部团队统一协作才能设计出适合业务发展方向的系统架构。从这个角度讲，架构师应该具备跨团队的技能。
如果一名架构师具备以上能力，那他就可以从事架构设计工作。对于具体的工作内容，任何一名团队成员都应明确其职责并赋予相应的权力，架构师自然也不例外。架构师的基本职责有3点。
●作为技术负责人，从问题领域出发进行抽象和建模并提供系统解决方案。
●与项目经理合作，制定计划、分配资源、组建团队。
●通过自身影响力和协作能力，保证项目按既定计划和成本完成。
定义并记录系统的架构、构建和部署系统的策略、确保架构满足系统的质量属性、促进系统级别决定的产出、确保相关决定与干系人的期望一致、对架构方面的各项指标做平衡性的判断并确保达成一致意见等都是架构师的职责示例。1.2.2 当程序员遇到架构师
当程序员遇到架构师能否碰撞出火花？我们从程序员的特点和架构师的要求两方面出发做一下对比，对比项包含以下12项。（1）思维模式
程序员、尤其是年轻的程序员的一大特征就是情绪化思维，对碰到的问题倾向于使用主观意识去寻找方法，同时又有一些顽固，钻牛角尖的场景并不少见。而架构师通常具备全面的思考和分析模式，倾向于使用换位思考从问题的内因、外因出发，找到团队内部和外部能够解决问题的资源，确保问题得以高效解决。（2）沟通
程序员普遍不善交流，表现在不善于听取别人的意见，更不善于表达自身的想法。而对于架构师而言，了解团队和组织文化，把握政治方向，具备沟通和协商能力是基本要求。（3）学习
程序员学习积极性高，能力也强，但过于依赖个人经验，并不能很好把握住学习的方向，缺少系统的学习计划和目标。架构师通常具备较强的自我提升意识，明白要学什么及怎么学。（4）协作
程序员创造力强，但在团队和组织氛围下，缺乏一定纪律性，往往从个人出发思考问题和开展活动。而架构师作为技术负责人，需要通过系统的工程学方法，应用项目管理知识领域及相关工程实践开展团队协作。（5）推动力
程序员独立思考，有好的想法但并不喜欢分享，更加不会作为推动者去主动落实这些想法。而架构师应具备领导力与推动力，除了技术演进，在团队价值取向、组织趋势把握、组织运营和人才发展等各个方面都可能需要发挥其主导性。（6）全局高度
程序员由于意识形态和经验的缺失，普遍过多关注细节而缺少大局观。而架构师具备全局观，拥有独特的基于系统架构设计的视图和视角。（7）方法论
程序员开发能力出众，但缺乏设计和建模的方法论。而架构师善于把握架构设计和系统建模的角度和切入点，并使用一组用于确保成功的手段、方式和流程。（8）业务
程序员相比业务更喜欢钻研技术，通常不关注业务，不善于从干系人角度出发理解业务并进行抽象。而对于架构师而言，理解干系人的业务痛点，并基于业务需求进行业务抽象和系统建模是其基本工作内容之一。（9）时间管理
程序员有很强的时间观念，但又不善于管理时间。而架构师善于采用敏捷、迭代的过程来合理安排时间，规避时间管理上的风险。（10）系统化
程序员拼命工作而不是聪明的工作，因为缺少系统化的工作规程。而架构师需要从系统工程角度出发，对软件开发、项目管理和过程改进等系统过程进行合理规划，形成统一的工作模式，确保团队成员都能在同一节奏上开展开发工作。（11）产品交付
程序员只关注写“高效”的代码，却不关心“高效”的产品交付。而架构师基于产品交付模型和工具进行产品的快速迭代及实现系统的自动化交付。（12）实用主义
程序员写“聪明”的代码而不是“简单”的代码，“聪明”的代码并不意味着一定能够带来更好的性能和可维护性，有时候反而成为团队知识传递的一种障碍。而架构师关注实用主义，追求成功而不是完美。
这12项对比中包含的思想和方法论在本书中都会一一展开。接下来，我们先来看一下架构师所应具备的视图和视角。1.3 架构师的视图和视角
架构设计是一项包含需求分析、质量管理和过程改进的系统工程，也需要跨团队的协作和交互。当需要把架构展示给别人时，如何表现架构设计、如何让别人快速而准确地理解进而实现架构就成为架构师的考虑点之一。通常，架构师会面临类似如下的疑问。
●架构能实现哪些功能？
●架构主要构成元素有哪些？
●架构中需要管理、存储和展示的信息有哪些？
●架构需要提供怎么样的开发、测试和部署环境？
面对这些疑问，我们的思路是避免用单个“面面俱到”的模型回答所有问题。这时候架构师手上应该有两项武器，一项是视图，一项是视角。视图和视角的分类业界也有几种不同的说法，我们站在前人[1]的基础上做出自己的阐述。
要想清晰、明确地展示系统架构的视图和视角，首先需要对视图和视角进行建模，即通过统一的表述方式和模型来展示不同的视图和视角。在本书中，每一个视图和视角将包含以下3部分内容。（1）定义
对视图和视角的简短描述，用于给出其一般定义。（2）切入点
描述某一个视图或视角特定的关注点，并提供切入该视图或视角的方向。任何一个视图或视角都应该具备若干与其他视图或视角不一样的切入点，以便在系统设计过程中能够找到问题所对应的切入点并进行优化和管控。（3）架构设计
包括架构设计过程中的模型和策略，对于视图和视角之间可能存在的相关关系也将属于架构设计讨论范畴。1.3.1 架构师的视图
架构视图面向需求，主要回答“有没有”这个问题。架构设计是一项综合性的活动，要完整展示架构包含的内容实属不易。架构视图为我们提供了六大视图，图1-12展示了这六大视图及架构设计与这些视图之间的关系，所有视图都是围绕架构设计展开，但又各自具备侧重点。通过完备的架构视图，系统架构就从一种抽象的概念转变成能够供干系人触碰的软件实体。图1-12 架构设计与视图
我们基于定义、切入点和架构设计这一建模方式对每个视图进行展开。1.上下文视图
所谓上下文（Context）指的就是一种环境。上下文视图描述系统与环境之间的关系、依赖和交互，包含了各种当前环境中数据及其操作。通常，上下文包含在特定的场景中，所以有时候我们也可以把场景（Scenario）这个词视同系统的上下文。
基于环境和交互，上下文视图的切入点往往同时关注于系统的内部和外部，系统的范围、系统之间的界限和外部系统的划分、组件和模块之间的依赖关系及如何进行系统有效集成等是上下文视图的主要展示内容。
架构设计方面，上下文视图总结我们所设计的架构背后究竟是怎么样的一个系统，包括系统本身、外部实体和相关接口。图1-13所展示的就是一个基于电商系统业务的上下文视图示例。可以看到，一个电商系统的内部包含账户系统、支付系统、物流系统等核心功能子系统，同时也需要和各种第三方系统进行集成。这时，相关数据都存储在本地数据库中，用户通过电商系统门户可以获取各个内部和外部子系统所提供的服务，从而提供了一幅完整的系统功能范围、外部系统集成和用户交互的上下文视图。图1-13 上下文视图示例2.功能视图
功能视图描述系统运行时功能元素及其职责、接口和交互关系。从定义上看，功能视图和上下文视图有一定的重合之处，但功能视图脱离环境，描述的是系统组件定义及各个组件之间的交互关系而不是业务场景分析，所以对于功能视图而言，我们结合组件设计思想进行理解。图1-14就是图1-13中上下文视图所对应的功能视图，采用UML （Unified Modeling Language，统一建模语言）中组件图进行绘制，可以进一步看到组件之间的接口和依赖关系。图1-14 功能视图示例
功能视图的切入点比较明确，就是从功能出发，包括系统的内部结构和外部接口，推导出该系统所需的各个组件及其依赖关系。内部结构取决于系统建模和架构分析的结果，而外部接口受系统集成模式和实现技术的约束。
功能视图的架构设计包括确定功能元素、接口、连接器和外部实体。这些在基于组件的设计方法中均有固定的表现形式。3.数据视图
业务系统软件通过数据来承载结果，大多数实现过程都是围绕数据展开。数据视图描述系统存储、操作、管理和分发数据的方式，是系统中核心业务数据的一种载体和表现形式。
数据视图对数据的处理包括几个主要方面，首要的是数据结构。数据结构作为表示数据的元数据，是系统内部最核心的数据模型。同时，为了能够在系统内部各模块及与外部系统之间进行有效交互和集成，数据标识符和映射关系同样成为数据设计的基本要求。数据一般都需要进行持久化管理，建立以传统关系型数据库、No SQL（Not Only SQL，非关系型数据库）亦或大数据平台为代表的数据存储模型是数据视图最后需要考虑的切入点。
数据架构建模有几种典型方式，包括静态数据建模、数据流建模和数据状态建模。这些数据模型代表着数据在不同场景下的不同表现形式以及发挥的作用。在UML中，类图、流程图和状态图分别可以作为静态数据模型、数据流模型和数据模型的建模工具，图1-15代表一个移动医疗行业中“病人”这一数据载体所展现的类图，而图1-16是围绕电商行业“订单”之一概念所做的数据状态图。两个示例都能在特定场景下为系统架构提供所需的数据视图。图1-15 数据视图中UML类图示例图1-16 数据视图中UML状态图示例4.开发视图
开发视图描述支持软件开发过程的架构。在所有架构视图中，该视图最接近于系统设计和具体实现方案，是架构设计中面向技术的核心视图。
系统设计和开发包含通用的体系结构和设计模式，其中系统模块的合理组织、软件复用技术的应用、使用设计和测试的标准化及如何进行代码组织都是开发视图常见的切入点。
上述切入点需要结合具体的业务需求并采用特定的架构设计模型方能展现成开发视图。模块结构模型是开发视图中比较容易实现且易于展示的一种模型。图1-17就是一个涉及用户和商品管理的电商系统中所展示出来的模块结构图，采用了UML中的包图作为特定展示媒介。从图中我们可以看到在架构设计和系统开发中时常需要考虑的一些设计模式，如系统分层（领域层、业务逻辑层和表现层）及这些层次之间的依赖关系。当然，开发视图中也可以包含一些通用的设计模型。图1-17 开发视图示例5.部署视图
部署视图描述系统部署的环境及系统与其中元素的依赖关系。通常，架构设计的结果会对系统部署有特定的约束条件；反过来，系统部署条件也会影响架构设计方案。这也是为什么要把部署作为单独一项架构设计视图的原因。
部署视图的切入点一般都比较程式化。系统部署时所需的运行平台、硬件设备和软件服务、第三方软件需求和网络需求是该视图的主要考虑点。通常这些考虑点已经包含了常见业务系统部署的各个方面。
部署架构上，平台模型、网络组成模型和技术依赖关系模型等在运行时需要通过部署视图展示给相关的服务发布和运维人员。特别是现在服务化架构大行其道的背景下，系统服务之间的调用关系远比传统意义上单块模式复杂，部署视图的重要性得到显著提升。UML中，我们可以使用部署视图对系统部署架构进行建模。图1-18就是一个典型的系统部署视图，包含了若干个服务提供者和消费者，这些服务通过Zookeeper进行分布式环境的集中式协调和管理。图1-18 部署视图示例6.运维视图
运维视图描述当系统运行在生产环境时如何进行运维、管理和支持。运维视图并不属于系统架构设计的核心视图。该视图也通常由专业的运维人员进行开发和维护。
运维视图和部署视图一样，切入点通常都比较程式化，如建立隔离的生产环境、运行时的功能/数据迁移、状态/性能监控、集中式或分布式的配置管理、数据和系统的备份和还原及提供各项技术支持等都是常见的运维要求。
架构设计上，运维视图的目的是为了保证服务的稳定性和可用性，并在系统出现运行故障时能够进行容错和快速恢复。这其中包括安装、迁移、管理和支持活动，并且希望这些活动能够尽量做到自动化。
六大视图之间虽然各自表现架构的某个方面，但也存在依赖关系，图1-19描述的是视图之间的依赖关系。从图中可以看到，开发视图作为唯一没有被依赖的视图处于架构设计的低端，正如同编码开发处于软件系统工程的下游一样；上下文视图顾名思义处于中间位置，为多个视图提供上下文环境信息；功能和数据视图之间耦合度较高，分别构成了独立的视图系统，因此往往共同存在和发展，类似的还有部署和运维视图。图1-19 视图之间的依赖关系
不同的系统往往对架构视图具有不同的展示要求。对上下文视图而言，主流的信息化系统、互联网系统、面向服务和中间件系统，重要性依次降低。因为信息化系统往往涉及较多的系统集成，而互联网站点则主要关注于系统内部的完备性，面向服务和中间件系统则更加专注于技术体系和指标，很少会关注业务及业务对应的交互方式。除了上下文视图，互联网系统对其他功能、数据、开发、部署和运维5个视图的要求都是最高的。面向服务和中间件系统因为系统特性一般不大关注数据和开发，而重点在于功能、部署和运维。信息化系统则对开发和部署具有较高要求，但不重视运维视图。1.3.2 架构师的视角
架构视角面向质量，主要回答“好不好”这个问题。架构视角并不像架构视图比较容易抽象，因为一个系统的质量属性包含很多内容。我们从中筛选出4个通用而又重要的架构视角，分别是安全性、性能、可用性和可扩展性，并采用与架构视图同样的建模方式对每个视角进行展开。1.安全性视角
安全性体现的是控制、监控和审计对资源的访问性和执行能力，以及从安全漏洞中恢复的能力。在主流的信息化系统、面向服务和中间件系统中通常要求不高，但对于互联网系统而言，安全性是一项核心非功能性需求。
从产生安全性问题的源头出发，我们可以找到常见的安全性视角切入点。需要进行安全性控制的内容通常称之为资源（Resource）。能访问资源的人或系统称为访问主体（Subject）。控制安全性就是根据不同的访问主体对不同的资源进行精细化控制，包含建立完善的用户权限管理系统并提供相应安全策略。
找到安全性切入点，架构设计上就可以对症下药。对用户进行身份认证（Authentication）、授权（Authorization）访问、通过加密解密等确保信息保密性和完整性、提供类似单点登录（Single Sign On，SSO）的安全性管理平台、使用第三方安全性基础框架等都是安全性架构设计的常见手段。2.性能视角
性能视角的质量要求体现在系统在其指定的性能状况下执行，以及将来需要时提供增长的处理能力。性能要求对于信息化系统而言，不一定会成为一项核心质量指标，因为一般的信息化系统偏重于业务模型而不大容易形成性能瓶颈。但对于互联网应用和中间件系统，很多时候是最核心的一项系统构建目标。
性能的切入点通常也有一套完整的方法论和工程实践。比如，我们可以从核心功能响应时间、系统吞吐量、部署架构的可伸缩性、性能问题的可预测性和峰值负载等方向判断系统是否存在性能问题并找到相应的解决方案。
架构策略上，也有很多针对性能问题掉设计方案，比如，对核心业务链路和活动进行分解并把串行操作转变成并行化流程、对需要重复执行的处理过程进行优化、重用资源和结果、使用异步处理、放松事务一致性、转换数据强一致性为弱一致性等都可以在一定程度上提升系统的性能。同时，在设计解决性问题时，也需要把握一定的平衡性，避免为了提升性能而提升性能。3.可用性视角
可用性视角提供系统在需要时能够完整地提供服务，并有效处理影响系统可用性故障的能力。和性能视角一样，可用性对于普通的信息化系统而言重要性居中，但对于互联网应用和中间件系统却是非常重要的。
可用性的规划和实现需要先明确服务的类型，对不同类型的服务其可用性要求不尽相同。系统升级、停机和维修时间、系统备份、灾难恢复等也都需要有对应的实施计划。
架构设计策略上，使用容错硬件和容错软件、确保采用主流的集群和负载均衡机制、加强日志管理和分析、采用组件复制策略、建立完整的备份和灾难恢复解决方案都属于这个视角的考虑范围之内。4.可扩展性视角
可扩展性视角是指系统在经历不可避免地变更时足够灵活，是针对提供这样的灵活性所要付出的成本进行平衡的能力。可扩展性对于信息化系统而言就有最高的重要性，对于面向服务和中间件系统具有最低的重要性，对于互联网应用而言，其重要性视具体系统而定。目前很多互联网应用，如移动医疗行业，因为核心数据都是存放在医院，业务系统需要通过各种技术手段对接医院内部的 HIS（Hospital Information System，医院信息系统）、LIS（Laboratory Information Management System，实验室信息管理系统）等，所以也具有较高的可扩展性要求。而对于电商行业而言，核心数据都属于内部系统可控范围之内，相对而言具备较低的可扩展性要求。
可扩展性（Extensibility）通常容易与可伸缩性（Scalability）混淆。所谓可扩展，扩展的是业务。所谓可伸缩，伸缩的是性能。图1-20上半部分代表可扩展性，当往系统A中添加新业务时，不需要改变原有的各个子系统而只需把新业务封闭在一个新的子系统中就能完成整体业务的升级，我们认为系统具有较好的可扩展性；而该图下半部分表示可伸缩性，即当系统B的性能出现问题时，我们只需要简单添加一个应用服务器就能避免系统出现性能瓶颈，那么该系统无疑具备可伸缩性。实际上，我们在前文的性能视角中已经提到过部署架构的可伸缩性概念。
明确了可扩展性的概念之后，我们明白实现可扩展性的一个切入点是加强产品管理，从业务需求的源头把控变化，把部分业务在进入开发流程之前进行梳理，以避免不需要的变化的引入。对于已经进入开发流程的变化，同样需要把握变化的维度和量级，并从变化交付、开发复杂度等角度出发找到提升可扩展性的方法。图1-20 可扩展性和可伸缩性对比
对于可扩展性视角，架构设计上的重点在于梳理系统的变化并把它们抽象成扩展点，并通过对这些扩展点创建可扩展的接口、应用促进变更的设计技术，以及尽量使用基于业务标准的扩展点技术等手段确保系统具有较高的可扩展性。
易用性视角、开发资源和效率视角、国际化视角等也属于系统架构的视角，但不属于架构设计的核心视角，故本书中不做展开。1.3.3 视图视角与系统工程
架构视图和架构视角垂直构成完整架构描述。我们可以在明确架构视图的前提下，往各个架构视图中添加架构视角，使视图和视角在完成各自目标的同时能够紧密整合。系统的可扩展性视角与功能、数据和开发视图关系密切，因为可扩展性面向业务需求，系统的功能和数据设计方案及具体采用的开发模式会很大程度上决定系统的可扩展性。而可用性对这3个视图关系不大。部署视图对系统的安全性、性能和可用性影响巨大，部署视图是系统得以实现的基本前提，部署方案成功与否从架构上决定了能够实现成功的安全性、性能和可用性。
回到系统工程，架构视图和架构视角也是系统工程的组成部分。图1-21展示视图视角与系统工程之间的关系。视图关联视角，两者构成了架构描述的一部分；同时视图从业务需求角度，视角从质量需求角度解决了干系人所提出的各种关注点。这些关注点实际上就是需要架构师去捕获的架构设计的输入。图1-21 视图视角与系统工程1.4 程序员如何向架构师成功转型
通过前面的介绍，我们已经明确了架构设计和架构师的基本概念，架构视图和视角也是代表架构师从事架构设计活动的主要维度。接下去要解决的问题就是如何从普通的开发人员成功转型成一名架构师。1.4.1 转型成功的三段式模型
转型需要一个过程，而任何过程一般都可以抽象成人、工具和流程的组合。但是对于转型过程而言，显然普适意义上的人、工具和流程并不能直接应用。如何找到更加有效的途径来完成从程序员到架构师的转变？本书提出了针对转型的特定过程模型，即图1-22所示的由思路、方法论和工程实践所构成的三段式模型。图1-22 转型三段式模型1.思路
思路意指思考的条理脉络，通俗的解释就是心里的想法。转型需要想法，但往架构师转型的想法却受以下 3 个方面限制：意识形态（Mindset）、环境（Environment）和决心（Determination）。意识形态是转型的触动点，当我们想去做一件事情而这件事情需要付出很大努力时，通常是意识形态发生了变化，从习惯于根据详细设计文档编写代码并完成功能自测，到根据业务需求抽象出系统模型并转变成架构描述。意识的转变是工作内容转变的前提，而意识形态很多时候决定了一个人发展的高度。但一个人所能达到的高度还很大程度受限于环境因素，好的环境和不好的环境对个人发展影响巨大，而我们往往无法改变环境，只能适应环境，所以是否具备一个良好的环境也是在转型之前需要进行梳理并作出判断，必要时也应该果断采取行动。思路的最后一点就是决心。当意识形态和环境因素都已经具备，决心变成是否能够转型的关键，毕竟想要成为一名合格甚至优秀的架构师可能要比想象的困难。2.方法论
所谓方法就是做事的手段、方式、流程，而方法论即一组方法的集合，也就是一组用于确保成功的规则的集合。对架构师而言，了解主流软件架构风格、模式和模型、通过整合各种架构体系形成自身的架构设计思想是一种方法论；能够对主流架构设计方法进行阐述、把握主流技术体系知识领域及相应的原理是一种方法论；围绕软件开发生命周期的系统工程，理解软件工程、业务架构、敏捷方法、产品交付等概念是一种方法论；作为架构师了解各种软技能需求及相应的应对方法也是一种方法论。理论指导实践，只有具备相关的方法论，才能用于工程实践。3.工程实践
在软件开发领域，我们经常提倡使用各种最佳实践（Best Practice）。最佳实践是一个管理学概念，认为存在某种技术、方法、过程、活动或机制可以使生产或管理实践的结果达到最优，并减少出错的可能性。把软件开发的最佳方式和开发人员个人做得最好的事项一一总结出来，就是组织的最佳实践。最佳实践包含在技术和非技术领域，包含在对人和事物的处理过程，也包含在架构师所应具备的各项软、硬能力中。要想成为一名架构师，对架构师所应该从事的各项活动都需要且能够提炼出最佳工程实践作为具体工作展开的输入和模板。1.4.2 转型思维导图
架构师转型面临的巨大挑战来自于架构师的工作特性及康威定律。
康威定律（Conway’s Law）指出设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。从传统的单块架构到目前非常流行的微服务架构实际就是这一定律的一种体现。现在很多开发团队本质上都是分布式的，单块架构的开发、测试、部署协调沟通成本巨大，严重影响效率且容易产生冲突。将单块架构解耦成微服务，每个团队开发、测试和发布自己负责的微服务，互不干扰，系统效率得到提升。可见，组织和系统架构之间有一个映射关系：一方面，如果组织结构和文化结构不支持，通常无法成功建立有效的系统架构；另一方面，如果系统设计或者架构不支持，那么你就无法成功建立一个高效的组织。
康威定律给我们的指导是设计系统架构之前，先看清组织结构和组织文化，再根据情况设计并调整系统架构。要做到这一点，架构师应该具备较高的综合能力。表1-1列示了普通研发工程师与架构师工作性质的对比，从对比中我们可以看到，架构师的工作不能只关注于技术，而更重要是站在团队和组织的角度看问题。表1-1 研发工程师与架构师工作性质对比
但是我们知道软件研发人员也具有自己的思想和方法论，因此，一方面作为技术人员自然崇尚技术能力，架构师应该具备较强的技术创新能力才能让下面的开发人员信服；另一方面，架构师需要把握团队架构，在组织文化下和外部团队进行有效协作，需要具备人员和过程的管理能力，能够使内部、外部的团队成员目标一致，实现架构师的自身价值。显然，要做到以上两个方面是困难的。软件行业特定的企业文化及开发人员特定的思维模式决定了架构师不同于一般主管，如图1-23所示，架构师角色要遵守的是一种跷跷板游戏规则，若稍有不慎就可能失去平衡。图1-23 架构师的挑战
面对架构师转型所需要克服的各项挑战及康威定律给我们带来的启示，结合转型成功所需要的三段式模型，我们得出了图1-24的转型思维导图。该图上半部分代表包含思路、方法论和工程实践的三段式模型，下半部分代表转型主题，包括体系结构、架构设计和技术实现三部分在内的系统架构设计知识领域，包括软件开发系统工程，也包括架构师所需的软能力。三段式模型指导着转型主题的落实，即对每一个转型主题，思路、方法论和工程实践都是我们进行转型的基本切入点；反过来，转型主题又推动着三段式模型的进一步成熟和改进。该转型思维导图构成了本书的基本行文框架。本书后续章节内容基本按照该图进行展开。图1-24 转型思维导图1.4.3 作为架构师开展工作
在进行转型之前，程序员可以分析和挖掘作为一名架构师是如何开展工作的，明白架构师的日常工作内容有助于理解架构师转型过程中可能会碰到的问题，以及抱着这些问题继续本书后续章节的转型之路。图1-25梳理了作为一名架构师所从事的典型工作内容。1.识别干系人
识别干系人的首要问题是明确谁是干系人。明确干系人可以使用图1-26中的干系人识别模型。该模型有两个步骤，首先从架构师自身出发，找到某一件与架构相关的事情，然后再通过事情找到与“我”相关的干系人。该模型虽然简单，但却可以避免找到不必要的干系人及错过所需要找的干系人。在识别干系人的过程中同样需要对干系人进行分类。理想的干系人应该具备见多识广、有担当、有权威和有代表性等特征。图1-25 架构师的一天
试读结束[说明：试读内容隐藏了图片]