软件设计与体系结构 8-5视图架构设计法

9-5视图架构设计1概述现代软件系统非常复杂，通常在某个具体的时间内只需将注意力集中在某几个结构上就像看病时，医生只是将注意力集中在某方面的人体结构上，骨科医生与心血管科医生关心不同的结构结构是元素本身的集合，而视图则是捕获和表达结构（文档描述）。虽然它们有区别，但在实际使用时则不严格区分，即从系统体系的角度说是结构，从文档角度说是视图。2概述软件架构是一种无法以简单的一维方式进行说明的复杂实体，从不同侧面的描述就是视图。架构的优势也在于使用视图：每个视图强调系统的某一个方面，同时忽视系统的其他方面，以便有助于处理或理解当前问题，描述完整的系统架构必须具备完整的视图集。本章所讨论的是五视图：逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图。作为一名架构师，你设计的架构其实是要给很多人看的，包括公司领导、产品、开发、测试和运维，那么你该如何把你设计的架构展示给别人呢？3概述系统的架构设计是在业务需求已经清晰的前提下进行的，假定在系统需求分析阶段已经确定了系统的功能和业务范围，也明确了系统运营需求。在上述需求还没有确定的情况下，不适宜开展系统的架构设计，需要回到需求分析阶段完善上述需求后再开展系统的架构设计。系统架构就是一些模型图，模型图是人们用来理解系统和沟通的工具。4概述这些模型图需要提供给系统相关干系人来理解系统，系统相关干系人有项目经理、产品经理、开发人员、系统运营维护人员、客户、项目投资人等。这些干系人有不同的知识背景，对同一架构模型图也会有不同的认知和理解：如果把开发架构模型图给产品经理或客户看，他们定然看不懂也不能理解；同样的道理，如果只把逻辑架构图给开发人员看，就不能正确地指导开发人员构建开发环境。5概述因此在进行系统架构设计时，需要从系统的不同维度进行设计，以满足系统相关干系人理解系统架构的需求。架构设计模型主要有逻辑架构、开发架构、数据架构、物理架构和运行架构五种模型图。一般来说需要设计的系统架构模型有逻辑架构、开发架构和物理架构三种架构模型图。数据架构模型一般放在数据库中进行设计，运行架构和物理架构基本相近，只是在物理架构中加了数据的流向，因此一些系统设计使用物理架构代替了运行架构。6概述五视图法做架构设计的步骤是逻辑架构->数据架构->开发架构->运行架构->物理架构。先要理清楚业务，画出领域模型后，你才能根据这个进行数据架构设计数据结构定好后，应该拆分几个微服务，确定技术栈等开发架构的事情就确定了，粗的有了在运行架构里把细的在运行架构里说明清楚，然后就可以设计物理架构了。7Agenda逻辑架构数据架构开发架构运行架构物理架构8/72逻辑架构逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。常用表达图形，静态图有包图、类图、对象图，动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。9/72逻辑架构如果拿汽车举例，那就是发动机模块中包含了哪些子模块（活塞，曲轴，连杆，缸体，缸盖等），发动机模块和变速箱模块之间的关联关系是什么，和底盘的关联关系是什么。发动机、底盘、变速箱和电子系统在整辆汽车中的职责、关系和约束分别是什么。这些都是用来指导汽车研发的。10/72逻辑架构逻辑架构着重考虑软件的功能性需求，如：系统划分成几个子系统，几个模块，向用户提供什么样的功能每个功能都是怎么样的操作流程与分支，如何通过界面与用户交互？怎么交互？应当涉及哪些业务实体，以及相互的关系？与哪些外部系统接口？逻辑架构主要是业务的设计，画用例图，梳理清楚业务需求。然后根据用例模型画相应流程图或文档对流程进行描述。有了流程图或文档描述后，下一步就是根据上面的内容进行领域建模。11/72自底向上还是自顶向下我们首先和产品方一起讨论产品方案的合理性，在产品方案合理的基础上，我们来开始识别用例，开始了一系列软件工程领域方面的措施。其整体过程如下图所示：12/72自底向上还是自顶向下不管是演绎还是归纳，都是抽象工作的一部分，而且都需要素材，这里的素材就是我们对需求、对业务的理解，以及对技术的深度广度的把握。没有素材，方法论掌握再好也得不出结果。素材哪里来呢？业务素材的来源大部分是你需要解决问题所在的领域比如我们在电商领域，那么我们就要多搜集电商领域的业务知识。如果我们在数据领域，自然要多搜集数据业务的相关知识。13/72自底向上还是自顶向下自顶向下推导的一个前置条件就是你需要知道“猪”长什么样。在架构上就是你需要知道这个架构的原来是是什么样子的，解决什么问题的。如果都不知道“猪”长什么样，那么就无从判断“猪”是不是适合当宠物了。此处需要有一定的业务领域理解力和领域经验14/72自底向上还是自顶向下而自底向上推导则没有这个问题，因为是看着“猪”来做推导的，知道“猪”的细节，这个细节的特点如何演绎，如何归纳，最后得出结论。所以当我们不熟悉一个大的业务的时候，我们自顶向下推导架构的难度是极大的，几乎不能完成。不了解业务或技术情况时定义出来的问题也未必是一个被正确定义的问题，容易给人造成一个印象：瞎指挥。这个时候如何在没有知识背景的情况下快速落地就得自底向上的来推导架构。在自底向上的过程中慢慢熟悉业务。15/72自底向上还是自顶向下但是如果工作中每每都是纯粹的自底向上的推导架构，是无法帮助我们来做技术的前瞻性布局的。此时架构师的成长就遇到的瓶颈，所以此时又要使用自顶向下的架构推导方式。综上所述，不管是自底向上，还是自顶向下，都是架构师需要掌握的技能。16/72自底向上还是自顶向下17/72自底向上还是自顶向下根据用例集合推导业务概念模型；根据用例中的动词和量词推导业务概念模型的关联关系；在特定的边界内根据模型的职责归纳子域。18/72自底向上还是自顶向下根据用例集合推导业务概念模型；根据用例中的动词和量词推导业务概念模型的关联关系；在特定的边界内根据模型的职责归纳子域。19/72对业务概念模型进行归纳业务模型图中，模型和模型连线（连线就是模型和模型连接线）比较紧密，我们趋向将其放到一个模块中，连线不是那么密切的，我们趋向于将它们放置在不同的模块中。然后我们再观察连线数/模型数，观察内聚度量是高了还是低了，通过这样的方式归纳完成之后，我们再来通过度量公式来度量各模块的内聚和耦合程度。20/72对业务概念模型进行归纳21/72Agenda逻辑架构数据架构开发架构运行架构物理架构22/72数据架构数据架构在两大知识体系中的坐标，即企业架构和数据管理，是两个重要的知识体系，数据架构是它们共同关心的内容。从企业架构角度看，数据是企业架构关注的重要内容，企业架构的目标就是要打造无边界信息流，也就是让数据在适当的时候、适当的地点提供给适当的对象使用。数据架构是企业架构中的一个架构领域。和应用架构一样，数据架构也是承上启下的，上承业务架构，数据是业务对象的描述，由应用产生数据，并在应用间使用和流转。同时数据的存储、处理和流转都需要技术架构的支撑。从数据管理角度来看，数据架构是其中一个领域。23/72数据架构1）客户A：即将实施新系统，他们召集所有人一起进行两小时的实施前数据模型的评审会议。在这个过程中，他们发现了一些重大的错误。结果他们很高兴把一些问题扼杀在萌芽状态，否则这将是未来的噩梦。2）客户B：购买了多个系统，但他们的数仓遗漏一个设计来支持一个客户可以有多个电子邮件地址。他们花了数周重构数仓才解决。如果更早关注数据模型设计，他们就会知道设计与他们的业务规则不匹配。24/72数据架构3）企业公司：正在建设一个人力资源系统，员工可以担任多个工作角色，在数据模型设计中表明员工可能有多个角色。这是数据建模的基本常识，但他们没有关注数据模型的设计。现在公司检查每一个业务系统，并将其与他们的企业级数据模型进行比较，因为他们的企业级数据模型就是他们的业务运营模式。25/72数据架构4）大型客户：现在要求供应商在交付软件之前遵守特定的数据标准。因为他们是一家大公司，基于他们的购买力，供应商必须遵守相关规则。公司对其系统的数据模型进行管控，后面数据资产的集成和服务就越能顺利进行。从另外一个角度来看，在项目早期时，为了快速验证，会以尽快上线运行为最主要的目标，架构设计会有数据结构部分，但不会过多设计。在项目快速发展之后，频繁的表结构变更、数据类型变化会带来一系列的问题，尤其是当可能发生拆库、分表等动作之后，带来几个典型的数据问题：26/72数据架构1）数据标准不一致：列名相同，数据类型不同；列名相同，数据类型相同，长度不同；列名定义没有统一标准，识别困难；列名定义不统一，类型不统一，长度不同。2）数据模型混乱表、字段缺乏注释；表无主键、允许为NULL列；表关系不清晰；不合理的冗余设计。3）性能问题：对表结构、索引理解、使用不当；SQL的编写与开发者的技术水平有关，当SQL编写不当且缺乏审核导致带入线上，就会导致性能问题。4）数据缺乏安全管理表结构规范；索引合理性设计、创建检查；SQL质量；数据安全管理（插入、删除、更新，以及批量查询动作）。27/72数据架构28/72数据架构29/72数据架构简单来说就是“人对企业业务的表达、记录，并转化为计算机可处理的格式”，是连接数据与信息的桥梁。某航空公司为了适应这个趋势，专门成立了数据架构部，负责建立维护管理企业整体数据架构。一般认为企业的数据架构，主要有三个组件构成，分别是数据标准、企业模型和数据存储结构。数据架构30/72两种数据架构设计模式31/72模式一：从技术到业务，也可以称为Bottom-up模式。典型特征是先定义主题域，在从现有操作性数据结构出发，通过调研和访谈，规划数据架构，实现数据到信息的打通。两种数据架构设计模式32/72模式二：从业务到技术，也可以称为Top-Down模式。其特征是以业务流程为主线，串联业务单元、业务环节、业务活动。分析业务活动所需的实体、属性。两种数据架构设计模式33/72两种数据架构设计模式34/721）从技术到业务模式例子：确定了10个数据主题域，同时又分析了数仓的模型中2000多个实体，对现有系统的数据结构进行调研确认，从而构建了企业数据模型。两种数据架构设计模式35/722）从业务到技术模式的案例：下图是某航空公司飞机运行生命周期管理业务流程。从规划发展部做飞机引进计划，到飞机投入运营，再到飞机退出，每个业务环节都会产生业务数据。两种数据架构设计模式36/72数据中台：（1）什么是前台和后台在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：一个绿色图标的应用，里面有我的A、B、C好友。而后台则是包含两个部分：企业的内部管理服务的统称，如内部的CRM、ERP等；为前台提供服务能力的如：数据压缩能力、并发等。37/72数据中台：（1）什么是前台和后台后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发、传输速度而记住微信这个品牌。也就是说，后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。在开始谈论中台之前，我们先要明白当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新的业务场景。38/72数据中台：（1）什么是前台和后台这种前后台反而是公司最省事省力的一种提供服务的解决方案。因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。实际上中台的出现更多是因为：公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题、而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。39/72数据中台：（1）什么是前台和后台而作为实际用户真正接触的前台业务，如：APP，小程序，网站等，必须要快速迭代新的功能才能让用户感知到。而在这个大背景下带来的矛盾就是：以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统。由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原来的前后台模式的这种直接关联决定了两者的冲突不可避免。40/72数据中台：（1）什么是前台和后台例如：传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式（拼团、一元购等）：导致每次活动页面开发的时候，不仅需要前端重新设计页面，从后台接口提供与数据表都要重新设计。这无疑大大拉长了我们的需求响应时间，很有可能会导致在活动模块还没开发完成，我们的风口就已经过去了。因此我们需要一个能最少改动、就能完成大部分需求的解决方案，这就是中台。41/72数据中台：（1）什么是前台和后台中台解决方案到底是什么呢？让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易的理解这个概念了。首先请大家想一个问题，在一家客流量非常大的餐厅中、我们要如何缩短客人的等待时间呢？相信很多人的第一想法就是增加多名厨师，但是大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的。42/72数据中台：（1）什么是前台和后台而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里：厨师人员就显得非常冗余了。而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考。也就是将做菜变为：43/72数据中台：（1）什么是前台和后台通过这样的拆分后我们可以发现：无论是做什么菜系，买菜与配菜都是共有的两个步骤我们完全可以只需要增加一位配菜的小哥、来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：44/72数据中台：（1）什么是前台和后台这样我们每一位厨师新做一道菜时没有必要一定要从买菜、洗菜、切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅。唯一需要关心的就是如何在搭配调料上研究不同的创意。这样完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人、就解决了所有问题。回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。45/72数据中台：（1）什么是前台和后台厨师是我们的一个个的业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系而在业务多元化后洗菜、切菜和配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可。当然这里的配菜小哥就是我们的中台。所以说有了中台之后我们的前台业务就可以快速尝试迭代，不需要每件事都是从0到1开始了。46/72数据中台：（1）什么是前台和后台让我们再站在架构的层面来看看中台对整个系统业务所起到的作用。假设我们是一个电商平台、在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，就像下图：47/72数据中台：（1）什么是前台和后台而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务前台的特征加入适配。这样造成的结果：（1）后台的每一个模块都需要加入与前台适配的部分，从而大大加大了开发量；（2）每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量；（3）当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。48/72数据中台：（1）什么是前台和后台当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端同时对后台各个子系统进行统一的封装，让前台能无感知的使用各项服务而不需要单独设计通道，我们的系统也就简化成了这个样子：49/72数据中台：（1）什么是前台和后台50/72数据中台：（1）什么是前台和后台51/72通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。用一句话来概括就是：中台的核心本质就是服务共享，目标是支持前台的快速创新或试错，而实现的手段是微服务架构、敏捷基础设施和公共基础服务。中台解决方案的组成=能力输出+标准化中间件case-1业务中台数据中台：（1）什么是前台和后台52/72第一部分：能力输出，所谓能力输出就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。并在这些业务层面中去提炼、哪些模块是以共性存在的，并会在每个新开拓的业务中不断使用，然后就把他归类到中台进行建设。这也就是中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。数据中台：（1）什么是前台和后台53/72例如我们规划了公司的核心方向是视频方向，未来可能会涉及的业务形态有：在线视频、视频直播、短视频......分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为：在线视频编辑、视频压缩、多人点播......完成拆分后我们就可以通过中台去实现这几个通用模块。值得提一下的是虽然这里在说中台要考虑复用性和扩展性等，但是要考虑多少，考虑多深这里又是一个非常考验产品功力的地方。数据中台：（1）什么是前台和后台54/72第二部分：标准化中间件（整合能力）。在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分、就是需要做一个将每个能力进行封装，形成一个统一的可供前台业务端方便使用的中间件。这里的统一具体表现在如下的几个方面：（1）不同终端中的叫法与含义；（2）定义统一化的输入输出。为什么要统一呢？数据中台：（1）什么是前台和后台55/72以往的前后台模式中同一家公司内的不同业务如：直播项目组，短视频项目组各自为战的时候，经常会出现一个事物被不同项目因为场景化的需求，而出现两个称呼的现象，但是实际上他们本质上是同一个事物。这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍：无法快速对接。例如：就拿一个用户昵称这个字段来看，在不同项目组中的应用中可能会叫：用户名称，用户昵称，称号，花名等。而在数据库中又可能会有不同的字段名称：username，UN，name等。因此我们需要一个中心化的产物帮助我们定义好这些个通用属性，使在公司中不同的业务端都能统一。数据中台：（1）什么是前台和后台56/72面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候，无论具体是什么业务前端都会是一个叫法和一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。因此，中台的目的是减少重复投入、提升交付质量、加快版本迭代、实现业务打通。这个目的还只是表现，算不上本质的诉求。中台建设的本质目的是为更高效地赋能业务，为其提供全面、稳定、快速的需求处理能力。中台是业务发展过程中自然而然产生的，一切的目标都是为了使能业务。数据中台：（2）数据中台57/72过去三十年，企业数据管理都以传统的IT架构为基础。每当技术部门为业务部门解决问题时，需要从业务需求的探查、技术壁垒的打通等从上到下各个方面来建设新系统。每个系统的建成都自成一体，各自满足业务部门的需求。这种情况不仅耗费各部门大量的精力也使得各个系统难以打通管理，无法形成更强大的数据能力。各种信息系统大多是独立建设的，无法做到信息的互联互通，导致形成了多个数据孤岛。数据中台的作用是融合新老信息，整合各个孤岛上的信息，快速形成数据服务能力，为企业经营决策、精细化运营提供支持。数据中台：（2）数据中台58/72数据中台和业务中台的区别：业务中台是抽象业务流程的共性形成通用业务服务能力，数据中台是抽象数据能力的共性形成通用数据服务能力。数据仓库的主要场景是：支持管理决策和业务分析，而数据中台则是：将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。数据中台：（2）数据中台59/72数据中台作为整个企业各个业务所需数据服务的提供方，通过自身的平台能力和业务对数据的不断滋养（业务数据化），会形成一套高效可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样一来，当出现新的市场变化，需要构建新的前台应用时，数据中台可以迅速提供数据服务（服务业务化），从而敏捷地响应企业的创新。数据中台：（2）数据中台60/72目前的IT辅助管理系统是以欧美国家发达的制造业为奠定基础的，其更多的功能是采集数据，各个系统数据孤立存在、烟囱林立。在今天新的产业互联网时代，企业需要快速响应外部变化，建立多维度的数据以重塑DT（DataTechnology）的应用。因此传统的架构并不适合现在的市场发展情况，数据中台的架构颠覆了过去三十年传统的IT数据管理架构。数据中台：（2）数据中台61/72数据中台：（2）数据中台62/72如果以通俗化的生活案例来解说的话，数据中台的工作原理如同五星级饭店为满足食客需求的工作过程。数据类似于大型饭店中所用的果蔬肉等基础食材，CRM、ERP等管理系统将数据采集到，放到数据库里。为满足不同用户（食客的用餐）需求，企业需要将数据库中汇总的数据放到中央厨房以备业务人员（厨师）制作。数据放置的过程同步功能将数据分门别类，就像通过物流系统运送不同的食材到食材库里，将食材按类分拨。同时，数据治理技术需要将数据清洗好，对于某些特殊要求的数据还需要深加工等。数据中台：（3）数据中台的业务价值63/72从洞察走向赋能业务创新，形成核心壁垒。以客户为中心，用洞察驱动企业稳健行动。数据中台极大提升数据的应用能力，将海量数据转化为高质量数据资产，为企业提供更深层的客户洞察，从而为客户提供更具个性化和智能化的产品和服务。以数据为基础，支持大规模商业模式创新，依托数据和算法，将由海量数据提炼的洞察转化为行动，才能推动大规模的商业创新。case-2数据中台数据中台：（4）数据中台的技术价值64/72技术价值：能力多、成本低、应用广针对不同的数据应用场景，需要能够快速应对多数据处理需求，比如：要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、OracleRAC）；针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、SparkStreaming、Flink）；针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、ElasticSearch、Impala）；针对高并发业务场景（如用户画像），需要在线计算能力（MySQL、Redis、Oracle）。数据中台：（5）分层设计结构65/72数据中台是将企业的数据变成数据资产，并提供数据能力组件和运行机制的平台，简单来说就是数据集散中心。企业所有业务数据都经过数据中台的统一存储清洗和建模，转化为有用的数据资产，反哺给业务做决策参考。对企业来说，搭建数据中台确实能够解决诸如数据管理混乱、数据量过大等问题。数据中台的架构设计是有迹可循的，基本上来说都分不开---基础服务、数据收集、数据清洗整合、数据挖掘分析、数据服务管理和数据应用以及数据安全这七层。Agenda逻辑架构数据架构开发架构运行架构物理架构66/72开发架构软件架构中的开发架构是指软件开发过程中使用的技术架构，它描述了软件开发过程中使用的技术，技术架构的组件，以及它们之间的关系。开发架构设计关注软件开发环境中软件模块的实际组织方式，即软件系统由那些程序包组成，以及它们之间的关系。开发架构设计的重点考虑开发期质量，软件模块的组织有利于可扩展性、可重用性、可移植性、易理解性、易测试性等，设计中的关键技术主要体现软件开发期质量有关的设计，如设计模式的运用，框架的选择等。67/72开发架构68/72开发架构69/72技术架构解决的问题包括：❶如何进行纯技术层面的分层、❷开发框架的选择、❸开发语言的选择、❹涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对于的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是：根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。开发架构70/72技术架构面临最大的挑战是“不确定性”。在技术架构上，很多时候就会面临这种选择。是要选择业界最新的技术？还是选择团队最熟悉的技术？如果选择最新的技术，遇到新技术出了问题怎么解决？如果选择目前熟悉的技术，后续技术演进怎么办？这些都是架构师在做技术架构过程中需要考虑的。业务在千变万化、技术在层出不穷，没有一套通用的技术架构模式来适用所有的系统。那么，我们如何保证在做技术架构时，能够实现一个稳定、出色的系统。设计原则-战略71/72合适原则：技术人员有一种很强的技术情怀，就是在做设计的过程中，很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界的还要牛的轮子。这样才能够显示出自己的优秀，以至于不让自己显的那么平庸。比如，在项目中使用最新的技术，能让系统承担亿级用户的访问。那么现实是，如果在设计过程中一味追求新技术，往往失败的可能性很高。现实环境中我们一个业务团队可能就十几个人，项目工期短、上线要求快。在这种情况下，如果还要抽调几个人去研究、搭建、维护新的技术框架，对于项目势必会造成延期的影响。设计原则-战略72/72如果我们也想自己做一套类似的技术，不是说不可能。我们需要集合当下的技术实力、技术积累，做出适合自己团队情况的技术评估。没有最新，只要最合适。所有新的技术刚出来都是打着比旧技术拥有更加出色的性能、提供更加优秀的扩展性。是不是使用新技术，就能解决一切问题了？新技术的出道，势必是解决某一场景下的问题，并不是一味万能良药。只有了解清楚每种技术的产生背景，适用场景，才能出一个对自己项目最优的选择。技术选型没有最新，只有最合适。总结一下，合适原则就是“适合优于业界领先”。设计原则-战略73/72简单原则：我们总是希望能将我们的软件设计的精美、宏大，这样才能彰显我们系统的复杂度和难度。系统是不是一定要设计的复杂？在回答这个问题前，我们先看下软件领域的结构复杂性和逻辑复杂性。结构复杂性结构复杂的系统有两个特点：第一，组成的组件数量很多；第二，这些组件之间的关系很复杂。结构上的复杂性存在的第一个问题是，组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。设计原则-战略74/72假设组件的故障概率是1%（即：有1%的时间不可用），那么2个组件的系统可用性是99%*99%=98%，5个组件的系统可用性是99%*99%*99%*99%*99%=95%，两者相差3%。说明组件越多，系统稳定性就越差。设计原则-战略75/72结构上的复杂性存在的第二个问题是，某个组件改动，会影响关联的组件。逻辑复杂性意识到结构复杂性的问题后，只要减少组件就能让系统结构变简单？这样做还是行不通，原因在于除了结构的复杂性，还有逻辑的复杂性我们试想一下，把淘宝的所有功能都在一个组件中实现，可以想象这个系统要有多庞大：几百人维护一个系统、代码分支几十个、需求变更应接不暇、不同分支的回归测试、修改一段代码可能影响整个系统的运行等。这些场景相信大家都不希望看到的。总结一下，简单原则就是“大道至简”。设计原则-战略76/72演化原则：软件架构和建筑架构很多相同的地方，架构这个词也是从建筑领域借鉴过来的。比如，软件架构描述的是系统的结构、以及各模块之间的关系。而建筑结构描述的是一幢建筑的结构，以及建筑内部各部件如何有机的组成。但是，软件架构和建筑架构有一个本质上的差异：那就是建筑一旦完成就不会再变，而软件却需要根据业务的发展不断的变化。对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。设计原则-战略77/72所以技术架构设计需要一个过程：首先，要满足当前的业务需求进行技术架构设计。其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使架构逐渐完善。第三，当业务发生变化时，架构要扩展、重构、甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计却可以在新架构中延续。总结一下，演化原则就是“演化优于一步到位”。设计原则-战术78/72战术层的设计原则分为高并发原则和高可用原则。这些原则是对技术架构设计过程中提供详细的指导思路，帮助你做技术选型、技术拆分。高并发原则：设计高并发的系统，需要考虑以下几个方面的设计：无状态、拆分、服务化、消息队列、数据异构、缓存。高可用原则：降级、限流、可回滚。case-3技术架构设计步骤79/72第一步：识别复杂度：将复杂的问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。第二步：设计备选方案：备选方案3-5个较好；备选方案差异要比较明显；备选方案技术不要只局限于已经熟悉的技术。第三步：评估和选择备选方案：列出我们需要关注的质量属性点，然后分别从这些属性的维度进行评估每个方案，再综合挑选适合当时情况的最优方案。第四步：详细方案设计：数据库表设计、数据备份设计、主备服务器如何倒换、消息队列设计、服务通信设计等。Agenda逻辑架构数据架构开发架构运行架构物理架构80/72运行架构运行架构的着重考虑运行期质量属性，特别是非功能性需求，关注点是系统的性能、高可用性、可靠性、吞吐量、并发、同步、通信等问题。架构师的技术能力在这个阶段可以淋漓尽致的发挥出来。设计要点：（1）N+1设计：系统中的每个组件都应做到没有单点故障；（2）回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；（3）禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；81/72运行架构（4）监控设计：在设计阶段就要考虑监控的手段；（5）多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；（6）采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；（7）资源隔离设计：应避免单一业务占用全部资源；（8）架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；82/72运行架构（9）非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；（10）使用商用硬件：商用硬件能有效降低硬件故障的机率；（11）快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；（12）无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。83/72架构重构的12条“军规”随着应用的不断发展，最初的架构往往面临着各种问题，比如无法满足客户的需求、无法实现应用的扩展、无法实现新的特性等等。在这种情况下，我们如何避免一些坑，尽量比较成功地实现架构的重构，是很多开发者和架构师亟需解决的问题。Uber工程主管RaffiKrikorian提出了12条规则，具有较好的参考价值：84/72架构重构的12条“军规”（1）确定重构的目的和必要性看起来这个规矩有些多余，但是请不要忽略。每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元气。所以决策者们首先要分析架构重构的理由和其他备选方案，明确重构的目的：是为了满足业务需求，并且是不得不做的最佳方案，然后再考虑其他问题。有时候，经过分析就会发现，也许还有其他解决方案，比如增加计算资源，或者重构的目的不是为了业务需求，那就没有必要做了。85/72架构重构的12条“军规”（2）定义“重构完成”的界限如果确定要重构，那么要把目标明确下来，也就是：重构的边界条件，怎么才算是“完成”了重构。目标要有数据量化，或者有能够测试的办法。这也是一个需求分析的过程，如果需求不明确，那么规格说明书没法写清楚，负责重构的团队也没有明确的目标，不能以重构的时间或者主观的判断为结束的依据。86/72架构重构的12条“军规”（3）渐进式重构现在软件研发最流行的就是快速迭代、持续交付、尽早反馈。这同样可以用在架构的重构上，重构过程的难度不亚于构建一个新产品。所以在设计重构的时候，要引入持续交付的流程，每一个重构步骤或者模块都要快速部署并得到反馈，以便评估重构的效果，及时作出策略调整。有人会说，我们的架构重构是釜底抽薪型的，没法渐进，只能一蹴而就。如果是这种情况，可以考虑在另外一套拷贝的系统中做重构，经过谨慎测试之后，将数据和业务迁移过去。87/72架构重构的12条“军规”（4）确定当前的架构状态在启动重构之前，团队要对当前的架构状态有清晰的了解，也就是设定好基准，以便评估重构的效果。根据经验，负责重构的架构师或者开发者，往往还没有搞清楚现有的架构设计，就开始重构了。结果经常出现这样的情况：重构到某个阶段，发现行不通，然后一拍脑袋说，哦，原来这块的架构是这个样的，是为了达到某某业务需求啊，这块不能动，得想别的办法。类似的例子在研发团队中时有发生，也提醒我们要慎重小心。记得有位哲人说过，了解别人很容易，了解自己却很难。88/72架构重构的12条“军规”（5）不要忽略数据数据的重要性不言而喻，业务都是以数据流为载体的，所以架构重构的本质就是对于数据流的重构。数据对重构的重要性主要体现在两个方面：在重构设计时，需要考虑业务数据的需求，重构之后的系统对于数据的存储、处理、分析等功能是否有影响；在重构过程中，考虑依靠数据甚至是实际的数据来验证重构的效果，提供评估的支持。89/72架构重构的12条“军规”（6）管理好技术债务技术债务在平常的软件研发过程中也是比较突出的问题，现在单独拿出来强调是希望提醒开发者们：架构重构往往是为了偿还技术债务，所以请不要在偿还技术债务的过程中制造技术债务了。技术债务就像信用卡一样，会有很高的利息率，就如同给团队留下了大量的帐务开销。组织应该培养一种保证设计质量的文化。应当鼓励重构、同时也应当鼓励持续设计以及其它有关代码质量的实践。在开发时间中应当专门抽出一部分以解决技术债务。如果没有合适的照料，那么真实世界中的代码会变得越来越复杂难懂。90/72架构重构的12条“军规”（7）远离那些虚荣的东西（例如使用“热门”的技术栈）架构的重构过程应该是以目标为导向，换句话说“注重实效”。对于技术人来说，一个经常被轻视的问题在于，喜欢追逐新鲜的热门技术，这其实是个好事情，说明技术人勇于创新，不断接受新技术。但是对于架构的重构这样的关键性任务来说，是不是新技术并不重要，重要的是能不能实现重构的目标。对于新技术来说，虽然热度大，但是人才储备还不足，大家踩过的坑还不多应该客观冷静地评估新技术和成熟技术对架构重构的影响和效果，以数据和经验来说话，而不要追赶时髦。91/72架构重构的12条“军规”（8）做好准备面对压力这条军规更像是对架构师们的心理建议，软件开发过程中，压力无处不在。对于架构重构来说，压力来源于多个方面：管理层、团队成员、同级部门等。说白了，架构重构对个人来说往往是一件出力不讨好的事情。和做一个新产品能够取得很高的赞赏相比，重构的成绩往往并不受领导重视，而且出了问题还要承担很大的责任。从软件开发角度看，做新产品是从0到1，而架构重构是从-1到1，复杂性和难度通常更大。92/72架构重构的12条“军规”（9）了解业务虽然看起来像是一句废话，特意把这条提出来一定是有理由的。架构重构的最终目的是改进业务，所以对于业务的了解将有助于架构师和技术人确定重构目标的优先级和关键路径。比如，我们需要知道：哪些关键业务的架构是不能碰的，哪些业务之间是互相关联的，哪些业务的架构是需要优先重构等。93/72架构重构的12条“军规”（10）做好面对非技术因素的准备这又是一个不那么让人舒服的建议。不管你是否愿意相信，技术在架构重构的影响因素中并不是最高的，我们还会涉及到商业利益、管理层偏好、大客户影响、办公室政治、站队问题等。对于架构师和技术人来说，这些因素往往不是他们所能掌控的。我们能做的就是，与利益相关者设定重构目标，然后，根据不同的影响因素，调整目标。请记住，不要死扛这个目标，当有人提出不同的意见时，要坦诚地和他们交流非技术因素的影响是客观存在的，而且从商业层面来说也是合理的，所以对于技术人来说要学会适应。94/72架构重构的12条“军规”（11）对于代码质量有所掌握这和上述所提到的“管理好技术债务”有异曲同工之处。架构的重构对代码质量要求很高，一方面是重构过程对bug的容忍性比新产品的研发更低，另一方面也决定了下一次重构的难易程度。代码审查是一个非常好的办法。代码审查是软件开发过程中的必要步骤，既可以帮助被审查者提到代码质量，又可以让审查者加深对产品的理解。不论团队多忙，一定要保证代码提交之前，是经过其他成员审核过的，短期来看会占用团队的时间，长期来看是事半功倍的好事。95/72架构重构的12条“军规”（12）让团队做好准备这是RaffiKrikorian列举的最后一条军规，是对之前所有建议的总结。96/72如何行进重构通常情况下，需要架构重构的系统，除了业务本身的扩展外，基本上都是因为各种历史原因和历史问题没有及时处理。遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用、集中爆发！到了真正要开始重构的时候，架构师识别出系统关键的复杂度问题后，如果只针对这个复杂度问题进行架构重构，可能会发现还是无法落地。因为很多条件不具备或者有的问题没解决的情况下、就是不能做架构重构。因此，架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题。97/72如何行进重构拿某一个实际的项目来说，先整理系统目前存在的问题。大的项包括可用性、性能、安全、用户体验等，每个大项又包括十几二十个子项。但是实施时基本上就是挑软柿子捏，觉得哪个好落地、占用资源不太多，就挑来做，结果做了半年，好像做了很多功能，但整体却没什么进展。在原来整理的问题基础上，识别出架构的核心复杂度体现在庞大的系统集成了太多功能，可扩展性不足；但目前系统的可用性也不高，经常出线上问题，耗费大量的人力去处理。98/72如何行进重构99/72如何行进重构真正的架构重构在第三阶段，第一阶段和第二阶段都是为了第三阶段做准备而已。但如果没有第一阶段和第二阶段的铺垫，直接开始第三阶段的架构重构工作，架构重构方案需要糅合第一阶段和第二阶段的一些事项（例如，业务降级、接入服务中心等），会导致架构重构方案不聚焦，而且异常复杂。100/72如何行进重构为什么最终采用这样一个策略呢？主要还是为了：集中有限的资源，某个阶段集中解决某一类问题。这样做首先是效率高，因为阶段目标比较明确，做决策和方案的时候无须进行太多选择；其次是每个阶段都能看到明显的成果，给团队很大的信心。比如说第一阶段的“救火”，做完之后，系统很少有因为机器过载、缓存响应慢、虚拟机挂死等问题导致的故障了；完成第二阶段的事项后，因为组件、外部系统故障导致系统故障的问题也很少了。完成前两个阶段后，我们就可以安心地做第三阶段的“服务化”工作了。101/72如何行进重构举个例子，S系统的重构做法也是类似，但S系统当时面临的主要问题就是可用性不高，并没有系统耦合的问题。所以我们当时的策略是“先救火、后优化、再重构”。“救火”阶段做了扩容（防止资源不足导致系统被压死）和Nginx一键切换功能（故障时快速切换）；优化阶段将一些明显的可用性问题解决（包括性能问题等）；重构阶段将原来的单点数据库改为多中心。102/72case-4架构重构如何行进重构具体如何制定“分段实施”的策略呢？（1）优先级排序：将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。例如，扩容在S系统和X系统中都是最优先实施的，因为如果不扩容，系统隔三差五：一会出现响应超时报警，一会来个过载报警，一会来个大面积不可用……这些问题耗费大量的人力和精力，也就没法做其他事情了。（2）问题分类：将问题按照性质分类，每个阶段集中解决一类问题。例如，X系统的第二阶段，我们将多个底层系统切换到公司统一的公共组件，提升整体可用性。103/72如何行进重构（3）先易后难：这点与很多人的直觉不太一样，有人认为应该先攻克最难的问题，所谓“擒贼先擒王”，解决最难的问题后其他问题就不在话下。这样看起来很美好，但实际上不可行。首先，一开始就做最难的部分，会发现想要解决这个最难的问题，要先解决其他容易的问题。其次，最难的问题解决起来耗时都比较长，占用资源比较多。如果一开始做最难的，可能做了一两个月还没有什么进展和成果，会影响相关人员对项目的评价和看法，也可能影响团队士气。第三，刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。104/72如何行进重构采取“先易后难”的策略，能够很大程度上避免“先难后易”策略的问题。首先，随着项目的推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了。其次，先易后难能够比较快地看到成果，虽然成果可能不大，但至少能看到一些成效了，对后续的项目推进和提升团队士气有很大好处。第三，随着项目的进行，原来遗漏的一些点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效地保证整个重构的效果。105/72运行架构的演化运行架构最终要被部署到物理环境中，这样，运行架构和物理架构并非有个绝对分明的界限。比如：“把大表拆分为小表”的做法既可以理解为开发架构的范畴，也可以放在物理架构中来理解。（1）引入本地缓存和分布式缓存系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。在Tomcat同服务器上或同JVM中增加本地缓存，并在外部增加分布式缓存。数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。比如电商平台中缓存热门商品信息或热门商品的HTML页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。106/72运行架构的演化107/72缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢。运行架构的演化（2）数据库读写分离享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢？经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢。把数据库划分为读库和写库，读库可以有多个。通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。108/72运行架构的演化109/72业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。

运行架构的演化（3）数据库按业务分库为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线。应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。纵向拆分：将一个大应用拆分为多个小应用。横向拆分：将复用的业务拆分出来，独立部署为分布式服务。新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。110/72运行架构的演化111/72随着用户数的增长，单机的写库会逐渐会达到性能瓶颈。运行架构的演化（4）把大表拆分为小表比如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。这种做法显著的增加了数据库运维的难度，对DBA的要求较高。112/72运行架构的演化113/72数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈。运行架构的演化（5）引入NoSQL数据库和搜索引擎等技术任何强大的单一服务器都满足不了大型系统持续增长的业务需求。数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。114/72运行架构的演化当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变。对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决；对于keyvalue类型的数据，可通过HBase和Redis等方案解决；对于全文检索场景，可通过搜索引擎如ElasticSearch解决。115/72运行架构的演化116/72引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难。运行架构的演化（6）复用的功能抽离成微服务如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理。这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。117/72运行架构的演化118/72不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱。运行架构的演化（7）引入企业服务总线ESB屏蔽服务接口的访问差异通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务。服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构。119/72运行架构的演化120/72业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题。此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难。Agenda逻辑架构数据架构开发架构运行架构物理架构121/72物理架构软件的物理架构是相对于逻辑架构而言的。我们知道，软件系统的逻辑体系结构，是由一组支持系统逻辑操作的相关技术概念和原理组成。它与软件系统的组织有关，其主要目的是定义系统的结构，行为和接口协议。软件的物理架构规定了组成软件系统的物理元素、这些物理元素之间的关系、以及它们部署到硬件上的策略。硬件强大了，但数据量在增加，计算复杂度也在提高，所以增加硬件未必能解决问题。相反，计算与计算往往不是孤立的，它们之间存在着复杂的“生产者-消费者”关系所以软件的实际服务能力不仅受到“硬件资源”的制约，也受到了“数据短缺”和“数据争用”的制约。122/72物理架构每个架构师都应该懂得：增加硬件=增加计算能力≠软件的实际服务能力增强。多视图方法中，物理架构视图着重考虑运行软件的计算机、网络、硬件设施等情况，还包括如何将软件包部署（如果是嵌入系统则是烧写）到这些硬件资源上，以及它们运行时的配置情况。另外，物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。由于一部分运行质量属性需要硬件或网络的支持，所以物理架构必须关注如何配置硬件和网络来满足软件系统的可靠性、可伸缩性、持续可用性、性能、安全性等方面要求。123/72物理架构物理架构设计主要有3项任务：硬件选择和物理拓扑软件到硬件的映射关系方案的优化。物理架构的设计着重考虑安装和部署需求，关注点是：目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。124/72物理架构常见问题：系统如何发布部署？有哪些部署环境？系统有多少台机器？系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等。有没有容器化？有没有多机房部署？125/72物理架构相对逻辑架构设计而言，物理架构视图的设计是不是就乏善可陈呢？不，一般架构师最缺的就是物理架构的设计思路。从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。但是，思维当中经历了哪些思考、判断和权衡呢？从最终目标层面，决策要兼顾多方涉众的不同利益，可从“攻”与“守”两个方面理解：高性能（攻）、持续可用性（攻）、可伸缩性（攻）、技术可行性（守）、易维护性（守）......从思维要点层面，“开销”和“争用”是核心。126/72物理架构127/72物理架构的演化在介绍物理架构的演化之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：（1）分布式：系统中的多个模块在不同服务器上部署，即可称为分布式系统。如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上。（2）高可用：系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。128/72物理架构的演化（3）集群：一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。（4）负载均衡：请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的。129/72物理架构的演化（5）正向代理和反向代理：系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去。在外部网络看来就是：代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。130/72物理架构的演化（1）单机模式在部署时，主要从并发量和数据量两个方面考虑。当数据量和并发量都没有太大压力时一般选择单机模式，单机模式的特点是将运行环境（比如Tomcat或JBoss）和数据库安装在一台服务器上。用户通过浏览器访问服务器。131/72随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务。物理架构的演化（2）应用服务器和数据库服务器分开部署Tomcat和数据库分别独占服务器资源，显著提高两者各自性能。132/72随着用户数的增长，并发读写数据库成为瓶