1、架构概述

1.1 架构是什么

  在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。在不同的书籍上,不同的作者,对于架构的定义也不统一,角度不同,定义不同。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义,因为概念是人认识这个世界的基础和用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。
  Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念。

1.1.1 系统与子系统

  系统:泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。
  关联:系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台PC放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
  规则:系统内的个体需要按照指定的规则运作，而不是单个个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴,将动力输出到车轮上，从而驱动汽车前进。
  能力:系统能力与个体能力有本质的差别，系统能力不是是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机变速器、传动轴、车轮本身都不具备这样的能力。
  子系统:也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。

1.1.2 模块与组件

  都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。
  模块就是从逻辑上将系统分解，即分而治之，将复杂问题简单化。模块的粒度可大可小，可以是系统，几个子系统、某个服务，函数,类，方法、功能块等等。划分模块的主要目的是职责分离。
  组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。划分组件的主要目的的是单元复用。"组件"的英文单词Component，对应中文的"零件"一词，"零件"更容易理解一些。"零件"是一个物理的概念,并且具备"独立且可替换"的特点。

1.1.3 框架与架构

  框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范, 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。框架是组件实现的规范，例如:MVC、MVP、MVM等，是提供基础功能的产品，例如开源框架:Ruby on Rails、Spring、Laravel,Django等，这是可以拿来直接使用或者在此基础上二次开发。再例如,SpringMVC是MVC的开发框架，除了满足MVC的规范,Spring提供了很多基础功能来帮助我们实现功能，包括注解(@Controller等)、Spring Security、SpringJPA等很多基础功能。
  架构在TOGAF9是这么定义:一个系统基本的构件(子系统,模块,组件)，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。两种含义:
  (1)一个系统的形式化描述，或指导系统实现的构件级的详细计划。
  (2)一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略

  框架和架构的区别还是比较明显的，框架关注的是"规范",架构关注的是"结构"。框架的英文是Framework。例如，SpringMVC是"Web MVC Framework"。架构的英文是Architecture。例如，Linux操作系统的架构。

1.1.4 架构的定义

我在这重新定义架构(见仁见智，自己独立思考):软件架构指软件系统顶层结构设计。
架构是经过系统性地思考,权衡利弊之后在现有资源约束下的最合理决策,最终明确的系统骨架:包括子系统,模块,组件.以及他们之间协作关系,约束规范,指导原则.并由它来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。
涉及四方面:
1、系统性思考的合理决策:比如技术选型、解决实施方案(包括执行目标计划)、成本评估、性价比评估等等。2、结构:明确的系统骨架(结构)∶明确系统有哪些构件组成。
3、连接:系统协作关系:各个组成部分如何协作来实现业务请求。
4、规范:约束规范和指导原则:保证系统有序，高效、稳定运行，包括规范、原则、流程等内容。

1.2 架构设计的目的

如果没有架构设计，说明你的系统不够复杂。随着业务的增长，系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高，技术团队可能从一个团队变成多个专业化团队。假如没有架构设计，系统定会是一个无序失控的状态，带来的问题:
1、应用服务的边界不是很清晰∶到底该怎么拆分没有一个明确的原则，研发人员为了所谓微服务化而拆分，而不是从当前业务考虑。导致系统无序的状态，开发效率低。
我们系统出现过类似的情况:一个简单项目拆分成8个子服务，问他为什么这么拆分，说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过，接手人宁愿新开发一个项目也不愿重构。
2、应用服务层次不清晰，系统耦合严重:导致服务依赖出现网状依赖结构，牵一发动全身，后续修改和扩展困难。
3、系统应用服务跟踪问题:由于微服务化后，系统逻辑复杂，服务出现问题后，你很难快速的定位问题和修复。这是我们踩过不少坑，我们使用dubbo服务化，系统一旦出现问题，—推人手忙脚乱。
4、系统服务监控问题:由于研发人员基本没有服务监控意识，都是出现问题后再想办法如何添加服务监控接口。
5、技术体系失控问题:不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术，拿应用项目来试验新技术。
。 。 。 。 。能列举出来还有多各种各样问题。
架构设计的目的是为了解决系统复杂性带来的问题，其本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。从上面架构的定义，也知道架构设计的作用涉及四方面:1、系统性思考的合理决策。2、明确的系统骨架。3、系统协作关系。4.约束规范和指导原则。
架构的本质是管理和解决系统的复杂性，提高效率:
。管理复杂性:对系统进行有序化重构，不断减少系统的""商”，使系统不断进化，改善软件质量为目的的内在结构性变化;。提高效率:对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
无论是何种变化，架构师通过理解业务，全局把控，权衡业务需求和技术实现，选择合适技术，解决关键问题、指导研发落地实施，促进业务发展，提高效率。

1.3 什么样的系统需要做架构设计

那什么样的系统要考虑做架构设计?技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。1．需求相对复杂.
2．非功能性需求在整个系统占据重要位置.3．系统生命周期长,有扩展性需求.
4．系统基于组件或者集成的需要.5.业务流程再造的需要.

1.4 架构师需要具备的能力

1.5 架构师的职责

1.6 衡量架构的合理性指标

架构为业务服务，没有最优的架构，只有最合适的架构，架构始终以高效，稳定，安全为目标来衡量其合理性。
合理的架构设计:
1、业务需求角度
1、能解决当下业务需求和问题
2、高效完成业务需求:能以优雅且可复用的方式解决当下所有业务问题
3、前瞻性设计:能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。
2、非业务需求角度
(—)、稳定性。指标:
1.高可用:要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来—步—步推进。
(二)、高效指标:
1.文档化:不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。
2.可扩展:软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
3.高复用:为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
(三)、安全指标
1.安全:组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密https等为普遍手段

1.7 常见架构误区

误区1——架构专门由架构师来做，业务开发人员无需关注
架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓"千里之堤，溃于蚁穴"。
误区2——架构师确定了架构蓝图之后任务就结束了
架构不是*空中楼阁"，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道"地"在哪?怎么才能落的稳稳当当。
误区3——不做出完美的架构设计不开工
世上没有最好架构，只有最合适的架构,不要企图—步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车->目行车–>摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗?
误区4——为虚无的未来埋单而过度设计
在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。
误区5———味追随大公司的解决方案
由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了"淘宝就是这么搞的"或者“腾讯就是这么搞的”。
大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
误区6——为了技术而技术，
技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。

●开高走落不到实处
遗漏关键性约束与非功能需求
为虚无的未来埋单而过度设计
过早做出关键性决策
客户说啥就是啥成为传话筒
埋头干活儿缺乏前瞻性
架构设计还要考虑系统可测性
架构设计不要企图—步到位

2、架构分类

在EA架构领域，有两种常见架构方法RUP和TOGAF，这两个框架也是我们常常了解架构分类的两个维度。从我个人的角度觉得TOGAF的分类方式更加广泛使用。

2.1 业务架构（俯视架构）

包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。业务架构就是对企业的业务流程，进行根本性的再思考和在思考的彻底性再设计，从而获得成本、质量、速度等方面业绩的巨大的改善或提高。
总结业务架构包含:
1、战略
2、企业业务流程(价值链)当前能力，3、未来能力;商业能力，IT能力;
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。
看看京东业务架构(网上分享图)

2.2 应用架构

应用架构关注的是系统中各个应用程序组件之间的交互和关系。它描述了系统的模块化结构、功能划分和通信方式。应用架构定义了系统中的各个应用程序如何协同工作，以实现业务需求。它通常由软件架构师负责设计和定义，并结合业务架构提供的需求进行优化和调整。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。
应用架构在产品架构的基础上考虑两个事情:
第一、考虑的是子系统间的关系。
第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。

应用架构:应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面.应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。
应用架构图关键有2点:
1、职责划分:明确应用(各个逻辑模块或者子系统)边界1)逻辑分层
2)子系统、模块定义。3)）关键类。
2、职责之间的协作:
1)接口协议:应用对外输出的接口。2)协作关系:应用之间的调用关系。应用分层有两种方式:
一种是水平分(横向)，按照功能处理顺序划分应用，比如把系统分为web前端中间服务/后台任务，这是面向业务深度的划分。另一种是垂直分(纵向)，按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分
应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用!异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。
应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。
应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。
系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点;同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大)必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

2.3 技术架构

2.4 数据架构

数据架构指导数据库的设计.不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

2.5 代码架构

子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。
代码架构主要定义内容:
—、代码单元:
1、配置设计2、框架、类库。二、代码单元组织:
1、编码规范，编码的惯例。2、项目模块划分
3、顶层文件结构设计，比如mvc设计。4、依赖关系

2.6 部署架构

拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能,可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。

3、架构设计

3.1 架构设计原则

3.1.1 普适性架构设计原则

1、N+1设计∶开发的系统在发生故障时，至少有一个冗余的实例2、回滚设计∶确保系统可以向后兼容。
3、禁用设计:可以关闭任何发布功能
4、监控设计:在设计阶段就要考虑监控，而不是在部署完成后。5、多活数据中心设计
6、采用成熟的技术7、故障隔离︰8、水平扩展9、非核心则购买10、使用商品化硬件11、快速迭代
12、异步设计13、无状态设计14、前瞻性设计15、自动化

3.1.2 技术选型原则

架构设计并没有像编程语言那样的语法约束，更多的时候是面多多种可能时的“选择”，例如:。选先进的技术还是团队熟悉的技术?先进的出问题怎么办?熟悉的后续技术演化困难怎么办?。用Angular还是React，一个很强大一个更灵活
. MySQL还是MongoDB?
。淘宝的电商架构咳哟简单的照搬么?·等等
但存在共性原则:合适原则、简单原则、演化原则
1、合适原则:合适优于业界领先
优秀人才的技术情节导致各种以先进技术主导的创业失败，原因有:
1.将军难打无兵之仗(人数)
2.罗马不是—天建成的（(积累)3.水山下面才是关键(业务)

所以真正的优秀架构都是在企业当前人力、条件、业务等各种约束下设计出来的。能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。BAT的架构师到小公司没有了大公司的资源、平台、积累和业务，只照搬大公司的做法和技术即会失败!
我们架构设计核心目标是解决问题，提高效率。所以合适于业务场景需求的架构设计才是首要选择，而不是以追求实施性感时髦的新技术。
2、简单原则:简单优于复杂。
软件架构设计目的就是为了解决系统的复杂度。系统组成结构和相关之间关系越复杂，出问题的可能性就越大。扩展的难度也就越大，很有可能牵—发而动全身。
软件领域复杂度体现两个方面:
1)、结构的复杂性
。组成复杂系统的组件数量更多
。同时这些组件之间的关系也更加复杂
。组件增多整体出现鼓掌的概率增加，可用性下降。某个组件改动会影响关联的所有组件
。定位复杂系统的问题比简单系统更加困难
2)、逻辑的复杂性
·单组件承担功能过多，导致逻辑复杂度升高·后续的功能修改会影响很大
·使用了复杂的算法难以实现修改和问题解决
简单变复杂的事情可能人人都会，但化繁为简会很难。正所谓大道至简，如果简单和复杂的都能满足需求，最好选择简单的方案!

3、演化原则:演化优于一步到位.架构设计没有完美银弹.勿过度设计.
业务需求是不断变化的，所以架构设计需要不断随着业务变化而变化的，这样才能去适应业务需求。软件架构同建筑架构相似，但建筑不可变，软件可变,例如: Windows的演化、Android的发展。
软件架构类似于大自然“设计"的一个生物，通过演化适应环境，逐步变得强大。
1.首先满足当前需要,解决当前最核心问题.
2.预测并并发未来可能存在的问题,不断迭代保留，不断完善,3.业务变化时，架构扩展、重构、甚至重写。
不要贪大求全，分析清楚自身业务特点，快速落地，不断完善演化。当然如果一开始系统就有很好的基础设计,未来可能更容易到达满意的目标.
所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。例如在初创公司的野蛮生长阶段,业务场景和需求边界很难把握，有时候根本不需要架构师，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。这时候考虑如何做好架构设计,如何微服务化,可能会影响业务的发展.

3.1.3 程序设计原则

3.2 架构设计步骤

3.2.1 架构愿景

3.2.2 需求分析

3.2.3 架构设计

4、架构模式（大型架构演进过程）

4.1 从一个电商网站开始

4.2 数据库与应用分离

4.3 应用走向集群

4.4 读写分离

4.5 引入缓存

4.6 分库分表

4.7 微服务化

4.8 单元化

4.9 可信原生

5、互联网架构下核心技术实现

5.1 高可用

海恩法则
·事故的发生是量的积累的结果。
·再好的技术、再完美的规章，在实际操作层面也无法取代人自身的素质和责任心。
墨菲定律
任何事情都没有表面看起来那么简单。·所有事情的发展都会比你预计的时间长。·会出错的事总会出错。
·如果你担心某种情况发生，那么它更有可能发生。
警示我们，在互联网公司里，对生产环境发生的任何怪异现象和问题都不要轻易忽视，对于其背后的原因一定要彻查。同样，海恩法则也强调任何严重事故的背后都是多次小问题的积累，积累到一定的量级后会导致质变，严重的问题就会浮出水面。那么，我们需要对线上服务产生的任何征兆，哪怕是一个小问题，也要刨根问底:这就需要我们有技术攻关的能力，对任何现象都要秉着以下原则:为什么发生?发生了怎么应对?怎么恢复?怎么避免?对问题要彻查，不能因为问题的现象不明显而忽略。

5.2 高并发

5.3 高性能

6、架构书籍推荐

1.《大型网站技术架构:核心原理与案例分析》
这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。
2.《亿级流量网站架构核心技术》
相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理…统统都讲到了，而且配有核心代码。甚至连 Nginx的配置都有!
如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。
3.《架构即未来》
这是一本"神书"啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。
4.《分布式服务架构:原理、设计与实战》
这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是—本架构级、实战型的重量级著作。
5.《聊聊架构》
这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。
不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。
6.《软件架构师的12项修炼》
大多数时候所谓的"技术之玻璃天花板"其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。