一文带你了解架构设计

一、架构简介

想做好架构设计，第一步是将一个 IT 系统从应用层级至底层基础设施，全部拆解为一个个应用模块，可以称之为“元素”或“组件”；第二步是保证各个模块间不能孤立存在，还要做好充分的协作，协作通过应用模块对外暴露的“服务”来承载，也可以称之为“连接”。所以说，应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。

1.模块与组件

模块和组件都是一个系统的组成部分，只是从不同的角度划分系统而已。从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的就是职责分离；划分组件的主要目的就是单元复用。

2.耦合和内聚

(1)耦合

模块之间存在依赖，导致改动可能会互相影响，关系越紧密，耦合越强，模块独立性越差。比如模块A直接操作了模块B中数据，则视为强耦合，若A只是通过数据与模块B交互，则视为弱耦合。独立的模块便于扩展，维护，写单元测试，如果模块之间重重依赖，会极大降低开发效率。

设计应该以可测试性为第一目标。可测试往往意味着低耦合。一个模块可以很方便地进行测试，那么就可以说它是一个设计优良的模块。模块测试的第一步是环境模拟。模块依赖的模块列表、模块的输入输出，这些是模块测试的需要，也是模块耦合度的表征。

(2)内聚

模块内部的元素，关联性越强，则内聚越高，模块单一性更强。一个模块应当尽可能独立完成某个功能，如果有各种场景需要被引入到当前模块，代码质量将变得非常脆弱，这种情况建议拆分为多个模块。

3.框架与架构

从架构设计角度来说，模块的规格，也就是模块的接口，比模块的实现机制更重要。应着眼于模块而不是框架。框架是易变的。框架是业务流，可复用性相对更低。框架都将经历不断发展演化的过程，逐步得到完善。所以不让模块为框架买单。模块设计时应忽略框架的存在。认真审视模块的接口，发现其中“过度的（或多余的）” 约束条件，把它提高到足够通用的、普适的场景来看。

(1)架构与实现

①架构

架构是一种顶层设计，它描述了一个系统中的组成部分以及交互、协调工作的方式，强调软件系统的结构与行为设计。从逻辑上分可以把一个系统分成不同的模块，从物理部署上分可以将其分成不同的组件，从开发规范上分，可以将其分为MVC,MVP、DDD等。架构同时可能存在于不同的维度和层次上：

高维度：指系统、子系统或服务之间的切分与交互结构。
中维度：指系统、服务内部模块的切分与交互结构。
低维度：指模块组成的代码结构、数据结构、库表结构等。(比框架（架构图）更重要的是数据结构，比数据结构更重要的是接口。)

②实现

架构的实现就是围绕这种已定义的宏观结构去开发程序的过程，最终交付物是程序代码

确定了合适的选型后，需要从逻辑、控制与数据这三个方面进一步考虑程序设计：

逻辑，即功能的业务逻辑，反映了真实业务场景流程与分支，包含大量业务领域知识。
控制，即考虑业务逻辑的执行策略，哪些可以并行执行，哪些可以异步执行，哪些地方又必须同步等待结果并串行执行？
数据，包括数据结构、数据状态变化和存取方式。

开始编码实现时，进一步要考虑代码的执行效率，需要运行多长时间？要求的最大等待响应时间能否满足？并发吞吐能力如何？运行的稳定性和各种边界条件、异常处理是否考虑到了？上线后，出现 Bug，相关的监控、日志能否帮助快速定位？是否有动态线上配置和变更能力，可以快速修复一些问题？新上线版本时，你的程序是否考虑了兼容老版本的问题等？

代码是以什么形态交付？如果是提供一个程序库，则需要考虑相关的依赖复杂度和使用便利性，以及未来的升级管理。如果是提供服务，就需要考虑服务调用的管理、服务使用的统计监控，以及相关的 SLA 服务保障承诺。

③关注点

架构的一个核心关注点——熵，用以表达系统的混乱程度。软件系统或架构只会因为变化而腐坏。一开始清晰整洁的架构与实现着需求的变化而不断变得浑浊、混乱。这也就意味着系统的“熵”在不断增高。

系统只要是活跃的，“熵”值就会在生命周期中不断波动。需求的增加和改变，就是在不断增加“熵”值（系统的混乱程度）。但软件系统的“熵”有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了。这时，你可能将迫不得已采取一种行动：重写或对系统做架构升级。

那么，关于实现的核心关注点可以用一个字表达：简。关于实现的全部智慧都浓缩在了这一个字里，它不仅减少代码量，也减少了开发时间，减少了测试时间，减少了潜在Bug 的数量，甚至减少了未来的维护、理解与沟通成本。

架构设计不需要把每一次大大小小的变化，只需要掌握变化中偏向于战略的细节设计，而其他大量的实现细节只要没有越出顶层宏观结构定义的边界即可。系统是活的，控制演化的方向是可行的，而妄图掌控演化过程的每一步是不现实的。

④架构的目的

通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化。

架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。从简单的桌面应用发展到现在的大型互联网平台，这个过程中系统规模越来越大，业务和技术也越来越复杂。需要通过架构设计，消化复杂性带来的混乱，使系统始终处于一个有序状态，能够应对现有和将来的需求变化。
架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，然后将它们重新组合，形成更合理的关系。“分”就是把系统拆分为各个子系统、模块、组件。“合”就是基于业务流程和技术手段，把各个组件有机整合在一起。比如说在微服务架构中，拆分为具体微服务后，需要对这些服务进行归类和分层，有些属于底层基础服务，有些属于上层聚合服务，还要尽可能地实现服务的平台化，比如说的中台，这些都是合的思想体现。这个分与合的过程将系统的复杂性分解为两个层次：

首先，各个子系统承担独立的职责，内部包含了自身的复杂性。子系统的复杂性对外部是透明的，外部不用关心。
其次，子系统通过封装后，简化为职责明确的一个点，因此，我们只需要在合的过程中，解决各个点之间的依赖关系，这样就可以定义出系统整体。

通过合理的“分”与“合”，系统不是回到了原点，而是把原先铁板一块的系统变成一个富有弹性的结构化系统。这样，系统的复杂性有效地分解了，系统的有序度大幅度地提升了。

(2)框架

而框架是实现系统的一个半成品，定义了编码的规范。一个框架是一个可复用的设计组件，它统一定义了高层设计和接口，使得从框架构建应用程序变得非常容易。

开发过程不能过度使用框架，尽量减少无用框架的引入，因为框架不能完全保证能不没有错误的产生。

如今，框架带来的束缚在于，同一个问题，会有很多不同框架可供选择。如何了解、评估、选择与取舍框架，成了新的束缚。

4.架构域的分类

在软件设计中架构域是如何划分的，架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构。首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。

(1)业务架构

业务架构就是在业务需求初期，将模糊的需求描述转变成清晰的问题域，梳理出清晰的业务流程，为产品架构提供输入。讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助我们理解系统面临哪些问题以及如何处理

一个典型的交易流程，它包含商品浏览、商品加购物车、下单、支付等步骤，业务架构就是将这个流程中各个步骤抽象到不同的模块之中。购物流程 = 商品模块. 商品搜索 + 购物车模块. 添加商品 + 订单模块. 创建订单 + 支付模块. 支付

业务架构包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。

业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须设计软件架构。试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重建。经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。

①业务的可扩展

业务架构设计要能支持打造一个柔性系统，通过提供良好的业务扩展性，允许业务不断调整和快速生长。

业务的主题是变化和创新，系统的主题是稳定和可靠。这里把业务平台和业务线剥离开，让业务平台封装基础通用的功能，这样，它就变得相当地稳定；让各个业务线包含自己的个性化需求，业务线只依赖业务平台，业务线彼此之间互相独立，可以自由变化。这样的业务架构设计，就同时保证了系统的相对稳定和业务的快速创新。

②业务的可复用

对于类似的业务需求，如果原来做的工作可以大量复用的话，这是非常理想的结果，无论对于开发效率和开发质量的提升都很有帮助。

首先，模块的职责定位要非常清晰。对于模块来说，在定位范围内的职责要全部涵盖到，而不在这个范围的职责全部不要。
其次，模块的数据模型和接口设计要保证通用。架构师需要归纳业务场景，通过抽象提炼，形成通用化的设计，以此来满足多个类似场景的需求。
最后，实现模块的高复用，还需要做好业务的层次划分。我们知道，越是底层的业务，它就相对更固定。举个例子，同样是订单业务域，对于底层订单的增删改查功能，不同类型的订单都是一样的，但对于上层的订单生命周期管理，外卖订单和堂食订单可能就不一样。

所以，在做高复用设计时，可以尝试把一个业务域按照层次拆分得更细，比如，把订单模块拆分为多个上层订单模块和一个基础订单模块，这样，基础订单模块对于所有类型的订单，都能够提供复用。就拿当前非常流行的微服务架构来说，很多公司在微服务的基础上，通过服务分层，进一步落地了共享服务体系和中台架构，这些都是业务架构复用能力的体现。

(2)数据架构

企业架构由业务架构驱动，从业务架构分析业务流程、定义数据架构，流程和数据结合定义产品架构。这中间，数据架构起着至关重要的作用。企业 IT 系统的价值并不在于选取的技术有多先进，使用的硬件有多强大，而是企业业务数据的处理和存储。数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。

①数据模型——ER图加表设计

用来描述数据、组织数据和对数据进行操作，是对现实世界数据特征的描述。数据模型分类：概念模型，逻辑模型。

概念模型：是从普通用户的视角来描述数据的，使用简单的符号来描述信息，没有严格的规定，只要能清晰反映现实世界的信息就行。常用的就是E-R图。
逻辑数据模型：逻辑数据模型是严格定义的一组概念的集合，精确描述系统的静态、动态特性和完整性约束条件。逻辑数据模型通常由数据结构，数据操作和数据完整性约束条件组成。
- 数据结构：描述数据库对象的属性（类型，内容，性质），描述对象之间联系。是所描述对象类型的集合，是对系统静态特性的描述。
- 数据操作：允许对数据库对象的执行的操作和操作规则集合，一般数据库主要由（增删改查操作，还有其他操作）。是对系统动态性的描述。
- 数据完整性约束条件：对数据和数据库状态进行限制，使其保持数据正确，符合实际情况。如一个学生信息不能同时有两个学号，两个院系。

由于数据结构是刻画数据模型最重要的方面，所以，人们就用其数据结构来命名数据模型。

②系统需要什么样的数据

数据是对客观事物的真实表现，企业业务过程中的所有对象的状况都可以用数据记录下来。业务运营过程中有两条重要的线索：流程和数据。业务流程离不开数据流转，业务运营状况通过数据反映。基于业务架构的端到端的流程建模过程中，会衍生出对应的业务数据对象，需要与数据架构模型对接。流程模型和数据模型对接后落实到应用层面，就形成了产品架构。

数据架构中的数据包含静态数据和动态数据。相对静态部分如元数据、业务对象数据模型、主数据、共享数据。相对动态部分如数据流转、ETL、数据全生命周期管控治理。

③如何存储这些数据

数据架构是为了建立一个共享、通用、一致的数据基础平台，解决企业信息孤岛。如何存储业务数据，需要结合自身需求，采取合适的数据分布策略。通常，数据存储的分布策略有两种：一种是集中式存储，一种是分布式存储。

集中式存储就是讲数据集中存放于总部数据中心，所有的下属机构或子公司不放置和维护数据，都想总部数据中心进行访问。

分布式存储就是数据分布存放于总部、分支机构或者子公司，每个分布节点需要维护和管理自己的数据。分布式的数据存储架构中，还需要考虑每个分布式节点的数据与总部节点数据进行同步、备份，做到数据资产的安全、可靠。

④如何进行数据架构设计

数据源自于企业的业务流程，从业务流程中我们可以找出领域对象，基于领域对象进行分析，就能得到对象的属性。根据业务关系进而抽取领取对象之间的关系。因此，领域建模是一种对数据架构很有帮助的建模思想。通过领域建模不仅能清晰的反映企业的业务域，还能清晰的描绘出一幅企业的数据模型。数据模型最常用的视图就是 ER 图，它主要描述企业数据实体、属性和关系。

实体 (Entiy): 企业领域对象
属性 (Attribute): 领域对象的属性
联系 (RelationShip): 两个领域对象之间的关系 (1:1, 1:n 或者 m:n)

(3)产品架构

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

当打开一个系统，会看到一个精美的页面，一些丰富的信息、导航。这些东西会引导我们去使用这个系统。这些东西就是这个系统的组成部分，就是这个系统的功能模块。产品架构，就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。

功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。

产品架构中，功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。

当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了产品架构的分层。

(4)应用架构

应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的。这就是应用架构和应用集成架构。产品架构在业务架构的基础上，按照解决的业务问题域，划分出不同的功能模块，再根据功能模块间的关系，组合成子系统。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。应用架构在规划时，需要遵循以下几个原则：

简单性:体现在应用架构是否有清晰、明确的层次划分，各应用系统之间的连接关系是否简单确，系统之间的耦合程度低。
灵活性:体现在应用架构适应业务的快速变化，不仅要求在快速增加新应用时保持现有应用架构的稳定性，还要在适应业务变化的同时主动促进业务变革。
整合性:通过应用系统之间的解耦和组合，以统一的方式对外提供一致的服务接口，从而实现应用系统之间的共享和协作。

(5)技术架构

应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对于的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。

5.架构图分类

(1)4+1视图

①场景视图

用于描述系统的参与者与功能用例间的关系,反映系统的最终需求和交互设计，通常由用例图表示;

②逻辑视图

用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。

③物理视图

用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。

④处理流程视图

用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。

⑤开发视图

开发视图用于描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

(2) C4视图

①语境图

用于描述要我们要构建的系统是什么，用户是谁，需要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。

②容器图

容器图是把语境图里待建设的系统做了一个展开描述，主要受众是团队内部或外部的开发人员或运维人员，主要用来描述软件系统的整体形态，体现了高层次的技术决策与选型，系统中的职责是如何分布的，容器间是如何交互的。

③组件图

组件图是把某个容器进行展开，描述其内部的模块，主要是给内部开发人员看的，怎么去做代码的组织和构建，描述了系统由哪些组件/服务组成，了组件之间的关系和依赖，为软件开发如何分解交付提供了框架。

6.架构师职责

(1)关注点

不要因为自己是开发人员就不去关注软件运维，不要因为只是测试就不关注软件开发，因为你关注的越多你越能看清全局的价值目标。如果只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名流水线上焦虑至死的码农。试着转变思维，从架构师的角度思考价值问题，看看能否将技术贯穿到业务、到用户、到最终的价值去。

同理心的修炼：要有同理心，要有认同他人的能力。不要在没有全面理解他人思想的情况下去调整既有代码的设计逻辑。某些不好的设计方案可能是在特定场景下不得不做的妥协，不要轻易评判一个架构的好坏。
迭代能力的修炼：学会否定自己，经常对已有的代码进行重构
全局思维修炼：架构中的高可用，高性能都是为了满足目的而去实现的，架构设计最重要的目的是为了满足业务需求，实现盈利。所以在做架构的时候一定要考虑成本与收益，不能不计成本收益的去实现高可用和高性能
- 所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
- 空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？
- 比如人员编制，是按业务目标来配置。千万不要觉得团队有多少人，就承担多少人的工作量。

(2)架构师工作目标

在不同规模的团队中，存在不同维度的架构师，但不论工作在哪个维度的架构师，他们工作的共同点包括下面 4 个方面

确定边界：划定问题域、系统域的边界。
切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
连接交互：在切分的各部分之间建立连接交互的原则和机制。
组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。

架构师的交付成果是一整套决策流，文档仅仅是交付载体

二、架构关注点

架构设计应符合当下需求，能支撑3年内增长的业务流量即可——避免过度设计。

过度设计的现象常常存在，这种现象往往出现于极度追求完美的人和刚刚经历过首次开发设计不足的经验教训的人。过度设计的系统在最初就引入了过多的复杂性，导致开发举步维艰，这个问题或许在一个架构师有了一定经历后就自然能够解决，但是“第二个系统”的困境出现时，可以有意识地约束自己做出一些舍弃。

1.软件架构术语

单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。

(1)QPS和TPS,RT

QPS：Queries Per Second“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

并发量：QPS*平均响应时间

注：对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求就是QPS

RT：响应时间（Response Time），它可以理解为服务器处理响应的耗时。正常情况下响应时间（RT）越短，一秒钟处理的请求数（QPS）自然也就会越多，这在单线程处理的情况下看起来是线性的关系，即只要把每个请求的响应时间降到最低，那么性能就会最高。通过多线程，来处理请求。这样理论上就变成了“总 QPS =（1000ms / 响应时间）× 线程数量”，这样性能就和两个因素相关了，一个是一次响应的服务端耗时，一个是处理请求的线程数。

线程数对 QPS 的影响。单看“总 QPS”的计算公式，会觉得线程数越多 QPS 也就会越高，但这会一直正确吗？显然不是，线程数不是越多越好，因为线程本身也消耗资源，也受到其他因素的制约。例如线程越多系统的线程切换成本就会越高，而且每个线程也都会耗费一定内存。

当然，最好的办法是通过性能测试来发现最佳的线程数。换句话说，要提升性能我们就要减少 CPU 的执行时间，另外就是要设置一个合理的并发线程数，通过这两方面来显著提升服务器的性能。

入向流量 ≈ OPS * 请求包平均大小

出向流量 ≈ OPS * 应答包平均大小

(2)DAU/MAU

DAU: daily active user，日活跃用户数量

MAU: 月活跃用户量

(3)并发用户数

同一时间有多少用户在使用系统。对于网站来说，由于 HTTP 连接的无状态性，往往会使用服务端的会话数量来定义有多少用户同时访问系统。这个数字反应了系统的负载特性，也说明了系统同时处理请求的数目

(4)TP99

指的是请求中 99% 的请求能达到的性能，这里的 TP 是 Top Percentile 的缩写。比如，某系统响应时间的 TP99 是 1 秒，指的就是 99% 的请求，都可以在 1 秒之内响应，至于剩下的 1% 就不一定了。

性能平均数在真实的系统中往往不科学。举例来说，在一个系统的 100 个请求中，99 个都在 1 秒左右返回了，还有一个 100 秒还不返回，那平均时间会大于 (99 x 1 + 1 x 100) / 100，大约等于 2 秒，这显然不能反映系统的真实情况。因为那一个耗时特别长的请求其实是一个异常，而非正常的请求，正常的请求平均时间就是 1 秒，而 TP99 就比较能反映真实情况了，因为 TP99 就可以达到 1 秒。

有了 TP99 这样的概念，就可以定义系统的 SLA 了，SLA 是 Service-Level Agreement，它是系统对于它的客户所承诺的可以提供的服务质量，既包括功能，也包括性能。在性能方面，SLA 的核心定义往往就是基于 Top Percentile 来进行的。比方说，一个网站的 SLA (软件许可协议 - Software License Agreement)要求它对于浏览器响应时间的 TP95 为 3 秒。

(5)机架和IDC

①机架

为了方便管理维护众多的服务器，以及在服务器出现问题时候快速解决问题，可以采用机架的形式，将众多的服务器归纳到一个个机架里面去，机架之间的通信问题可以使用交换机来组织成为局域网

②IDC

互联网数据中心(INTERNET data Center)。它首要是为企业、媒体、网站供给大规模、高质量、安全可靠的互联网服务，首要包含：服务器托管、网站空间租用、带宽批发等业务。服务器的运作对周围环境的要求极高，并且还需要专门的技术人员保护，这就促进了许多企业需要一个好的机房和数据中心来放置网站，idc数据中心由此就诞生了。有了IDC数据中心，企业可以将与网站托管服务相关的一切业务交给IDC网络服务商来做，自己就可以把精力和时间放在产品研制和运作上，更能促进企业的前进和开展。

2.架构设计点

高可用、高性能、可扩展、安全、成本、规模、伸缩性

低成本和小规模是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。主要通过减少服务器和采用新技术实现。

伸缩性和高可用、高性能息息相关，它指的是当性能达到瓶颈时，可以简单的通过增加机器完成性能的提升。

(1)高性能架构设计关键点

为架构做好“保护系统”；保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。所谓流量控制，就是当实际并发压力，超过设计性能的时候，人为阻断服务器连接，告知用户需要排队或“稍后再试”。流量控制有两种具体的实践，一种是面向连接数做控制，一种是面向用户数做控制。前者让用户在不断尝试连接时，有一定成功的可能；后者则保证用户对系统的期望是一致的—— 要么可以登录、要么不能登录。具体应该选择哪种方式，取决于业务的实际诉求。
使架构具备扩容能力：储备额外的计算资源，提升弹性扩容的速度；
提升系统各组件处理能力：识别高并发情境中的资源争抢情况，同时注意保留架构的可扩展性。

(2)高可用设计关键点

保证系统高可用，架构设计的核心准则是：冗余(集群化)。有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来缩短故障时间，保证故障发生时，业务可以快速恢复。

(3)可扩展关键点

找到系统的变化点，并隔离变化点，从不确定中找到确定性。

(4)分布式系统的关键技术

服务治理。服务拆分、服务调用、服务发现、服务依赖、服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。
架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。
DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。
自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。
资源调度管理。应用层的自动化运维需要基础层的调度支持，也就是云计算 IaaS 层的计算、存储、网络等资源调度、隔离和管理。
整体架构监控。如果没有一个好的监控系统，那么自动化运维和资源调度管理只可能成为一个泡影，因为监控系统是你的眼睛。没有眼睛，没有数据，就无法进行高效的运维。所以说，监控是非常重要的部分。这里的监控需要对三层系统（应用层、中间件层、基础层）进行监控。
流量控制。最后是我们的流量控制，负载均衡、服务路由、熔断、降级、限流等和流量相关的调度都会在这里，包括灰度发布之类的功能也在这里。

要做好这么多的技术，或是要具备这么多的能力，简直就是一个门槛，是一个成本巨高无比的技术栈，看着就都头晕。要实现出来得投入多少人力、物力和时间啊。不过，我们应该庆幸自己生活在了一个非常不错的年代。今天有一个技术叫——Docker，通过 Docker 以及其衍生出来的 Kubernetes 之类的软件或解决方案，大大地降低了做上面很多事情的门槛。Docker 把软件和其运行的环境打成一个包，然后比较轻量级地启动和运行。在运行过程中，因为软件变成了服务可能会改变现有的环境。但是没关系，当你重新启动一个 Docker 的时候，环境又会变成初始化状态。

3.技术选型标准

(1)生产级

选择的技术栈是要解决实际业务问题和上生产抗流量的（选择不慎可能造成生产级事故），而不是简单做个POC或者Demo展示，所以生产级（Production Ready），可运维（Ops Ready），可治理，成熟稳定的技术才是我们的首选；

(2)一线互联网公司落地产品

尽量采用在一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品，它们已经在这些公司经过流量冲击，坑已经基本被填平，且被社区接受形成一个良好的社区生态。

(3)开源社区活跃度

Github上的stars的数量是一个重要指标，同时会参考其代码和文档更新频率（尤其是近年），这些指标直接反应开源产品的社区活跃度或者说生命力。

另外，对于不同业务体量和团队规模的公司，技术选型标准往往是不同的，创业公司的技术选型和BAT级别公司的技术选型标准可能完全不同。

4.架构设计三原则

架构即决策，架构设计需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。而决策就会存在不确定性。采用一些高屋建瓴的设计原则有助于去消除不确定，去逼近解决问题的最优解。

(1)合适原则

架构无优劣，但存合适性，架构设计并不一定要选择领先的技术，而是应该选择合适的技术。架构一定要匹配企业所在的业务阶段，所谓合适，一定要匹配业务所处阶段，能够合理地将资源整合在一起并发挥出最大功效，并能够快速落地。

比如项目开发初期为了快速上线只开发很少的功能，架构也不适合过度设计。所以将所有功能打包部署在一起，集中地进行开发、测试和运维，对于项目起步阶段，是最高效也是最节省成本的方式

(2)简单原则

简单优于复杂。面对系统结构、业务逻辑和复杂性，我们可以编写出复杂的系统，但在软件领域，复杂代表的是“问题”。

结构复杂性：组成复杂系统的组件数量多，同时这些组件之间的关系也很复杂，以至于一个组件发生改动会影响到关联的所有组件，同时由于组件多，出错的概率也变得高，而且由于组件多，出错时很难排查
逻辑复杂性：，为了解决结构复杂性，可能会考虑到将组件合并起来这就导致了逻辑复杂性，单个组件承担太多的功能，导致组件代码量很庞大，不易于维护等等，所以微服务的的服务划分很重要。

(3)演化原则

架构的不断优化优于一步到位，业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，针对核心需求，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

5.架构设计着重点

回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计。在设计阶段就要考虑监控的手段；
非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
使用商用硬件。商用硬件能有效降低硬件故障的机率；
快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；

6.架构图

(1)何时需要画架构图

在复杂项目开始前画:当要开始设计一个系统性、完整性的系统时，如果一开始就跳过设计产品架构图、技术架构图，直接开始写文档、画 demo，就很容易发生改了又改，做了又推翻的情况。

(2)如何画架构图

对复杂的系统，特别是前人没有做过的新系统，通常难以一下子设计出合适的架构。在架构设计的初期，通常都要经历一个不断探索的阶段。

在架构设计过程中，架构分解是必不可少的关键步骤。如何进行架构分解，从哪里入手开始进行分解？这些需要一套架构分解的过程模型和过程方法来指导分解。

从架构域的分类：业务架构、数据架构、产品架构、应用架构、技术架构这 5 个域，依次需要进行架构分解。每个结构域的分解过程，都是一个迭代过程。从无到有、从粗到细、从模糊到清晰，一步步精细化、丰富架构。迭代的过程就是一个否定之否定的过程，随着分解的逐步推进或系统的架构演化，后面的分解除了会识别出新的架构元素，也可能会对先前识别出的架构作出调整。整个架构分解的迭代过程，通过画架构图的方式是种非常直观的表现形式。