程序员蜕变为架构师必须要知道的「架构理论」

架构目的和指标

架构目的：

架构设计的主要目的是为了解决软件系统复杂度带来的问题，是用最小的人力成本来满足需求的开发和响应需求的变化，用最小的运行成本来保障软件的运行。让软件达到“高内聚、松耦合”，从而使软件具有:

• 易扩展——易于增加新的功能

• 更强壮——不容易被粗心的程序员破坏

• 可移植——能够在多样的环境下运行

• 更简单——容易理解、容易维护

设计目标:

• 可扩展性(Scalable)

• 可靠性(Reliable)，支持灰度发布，异地容错

• 可伸缩 (Extensible)，支持水平扩展和垂直增强

• 可维护性(Maintainable)，一是排除现有的错误，二是新需求可反映到现有系统中去。

• 安全性(Secure)

• 可定制化(Customizable)

• 客户体验(Customer Experience)，必须易于使用。

架构的方法论

​

面向对象

设计原则-SOLID

 

​

设计原则-SOLID

设计模式的六大原则有：

• Single Responsibility Principle：单一职责原则

• Open Closed Principle：开闭原则

• Liskov Substitution Principle：里氏替换原则

• Law of Demeter：迪米特法则

• Interface Segregation Principle：接口隔离原则

• Dependence Inversion Principle：依赖倒置原则

把这六个原则的首字母联合起来（ L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。

单一责任原则：

当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承担其他类型的责任的时候，就需要分解这个类。

开放封闭原则：

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。

里氏替换原则：

当一个子类的实例应该能够替换任何其他类的实例时，它们之间才具有is-A关系。

依赖倒置原则：

1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象

2. 抽象不应该依赖于细节，细节应该依赖于抽象

接口分离原则：

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。

设计模式类型

​

设计模式类型

CAP定理

CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指：

• 一致性（Consistency）：每次读操作都能保证返回的是最新数据；

• 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果；

• 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。

1.一致性：一致性是指数据在多个副本之间是否能够保持一致的特性。假如现在的多个节点中的数据是保持一致的，当执行完某一个更新操作之后，应当要保证系统的数据然后处于一致性的状态。对于一个将数据副本分布在不同的分布式节点上，如果对第一个结点的数据进行了更新的操作，并且更新成功之后，却没有让第二个节点得到相应的更新。当外部系统再去调用第二个节点时，获取到的依然是原始的数据，这就是分布式数据不一致的情况了。在分布式系统中，如果能够做到针对一个数据项更新操作执行成功之后，所有的用户都可以读取到最新的值，那么这样的系统就被认为是具有强一致性的。

2.可用性：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内，返回结果。有限的时间内：对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的结果。如果超过了这个时间，就认为系统是不可用的。返回结果是可用性的一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果包含成功或失败，而不是一个让用户迷惑的结果。

3.分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要对外提供满足一致性和可用性的服务。

​

CAP

一个分布式系统既然不能同时满足上述的三个需求，因此在进行对cap定理的应用时，我们就需要去抛弃一项。

①选择CA

放弃分区容错性，比较简单的方式就是把所有的数据都放在一个分布式节点上。那不就又成为了单机应用了吗？

②选择CP

放弃可用性，一旦出现网络故障，受到影响的服务需要再等待一定时间，因为系统处于不可用的状态。

③选择AP

放弃一致性，这里所指的一致性是强一致性，但是确保最终一致性。是很多分布式系统的选择。

小结：从cap的定理可以看出，分区容错性是一个最基本的要求，因为既然是一个分布式系统，必然要部署到两个或两个以上的节点上，否则，就不是分布式系统，因此我们只能在一致性和可用性寻求平衡。

BASE理论

​

BASE理论

base是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。base是对cap中一致性和可用性的权衡的结果。是根据cao理论演变而来，核心思想是即使无法做到强一致性，但是每个应用根据自身的业务特点，采用适当的方式来使系统达到最终与执行。

①基本可用

基本可用指的是分布式系统出现了不可预知故障的时候，允许损失部分可用性。响应时间合理延长，功能上适当做服务降级。

②弱状态

弱状态指的是允许系统中的数据存在中间状态，并认为该中间状态不会影响系统的整体可用性，即允许在各个节点数据同步时存在延时。

③最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步之后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证数据最终能够达到一致。而不需要实时保证系统数据的一致性。

AKF架构原则

​

AFK立方体

X轴扩展

所谓X轴代表把同样的工作或数据镜像分配给多个实体。换句话说就是复制服务然后负载均衡。这也是最简单最基础的扩展。

示例：我有个网站，一开始部署在服务器A上对外服务，随着访问人数增加，一台服务器的性能无法支持，于是我又在服务器上B上同样部署了网站，然后在前面部署了Apache或者Nginx来分流访问，这就是最基本的X轴扩展。

Y轴扩展

针对X轴扩展产生的问题，我们需要将大型服务进行拆解，把分割的工作指责和数据分配给多个实体这也就是Y轴扩展。也是微服务理论诞生的基础。

示例：我把网站的注册登录模块，首页新闻展示模块，后台维护模块拆成了多个微服务进行部署维护。 X轴扩展和Y轴扩展并不矛盾，是可以结合的，比如我发现新闻展示模块压力很大，我可以对新闻展示模块进行X轴扩展，部署多个镜像来分担压力。

Z轴扩展

Z轴代表按照客户、客户的需要、位置或者价值分割或分配工作职责。一般在超大型系统中，架构设计就会面临Z轴扩展的需求。

示例：网站一开始建设在上海数据中心，面向全国服务。随着公司业务的增长，西安的客户大量增加，但是访问上海数据中心速度很慢，所以公司考虑在西安建立数据中心来应对用户访问，这就是Z轴扩展。

康威定律

• 第一定律:企业沟通方式会通过系统设计表达出来

• 第二定律:再多的时间也没办法让任务完美至极，但总有时间能将它完成

• 第三定律:线型系统和线型组织架构间有潜在的异质同态特性

• 第四定律:大系统比小系统更适用于任务分解

架构思维

​

架构思维图

架构的变迁

​

架构的变迁图

单体架构：最简单架构风格所有代码在一个项目中，团队所有成员，可随时任意修改一段代码或增加一些新的代码。

​

单体架构图

Web应用程序发展的早期，大部分web工程师将所有的功能模块打包到一起并放在一 个web容器中运行，所有功能模块使用同一个数据库。

特点:

1、所有的功能集成在一个项目工程中。

2、所有的功能打在一个war包部署到服务器。

3、通过部署应用集群和数据库集群来提高系统的性能。

优点:

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

2、开发效率高，模块之间交互采用本地方法调用。

3、容易部署，运维成本小，直接打包到web容器即可运行。

4、容易测试，无依赖，在本地就可以启动调试完整的系统。

缺点:

1、全部功能集成在一个工程中，对于大型项目不易扩展及维护。

2、版本迭代速度逐渐变慢，修改就要将整个应用全部编译。

3、无法针对某业务按需伸缩。

垂直架构：分层是典型的对复 杂系统进行结构化 思考和抽象聚合的 通用方法，也符合金字塔原理。MVC是一个常见的三层架构模式。

​

垂直架构图

针对单体架构的不足，为了适应大型项目的开发需求，许多公司将一个单体系统按业 务垂直拆分为若干系统，系统之间通过网络交互来完成用户的业务处理，每个系统可 分布式部署，这种架构称为分布式架构。

特点:

1、按业务垂直拆分成一个一个的单体系统，此架构也称为垂直架构。

2、系统与系统之间的存在数据冗余，耦合性较大，如上图中三个项目都存在客户信息。

3、系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。

优点:

1、通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。

2、每个子系统可按需伸缩。

3、每个子系统可采用不同的技术。

缺点:

1、子系统之间存在数据冗余、功能冗余，耦合性高。

2、按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。

SOA架构：面向服务架构是一种建设企业IT生态系统的架构指导思想。SOA关注服务，服务是最基本的业务功能单元， 服务之间通过ESB通信。

​

SOA架构图

SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分， 并通过这些服务之间定义良好的接口和协议联系起来。

特点:

1、基于SOA的架构思想，将重复公用的功能抽取为组件，以服务的方式向各个系统提供服务。

2、各个系统与服务之间采用webservice、rpc等方式进行通信。

3、ESB企业服务总线作为系统与服务之间通信的桥梁。

优点:

1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

2、可以针对不同服务的特点按需伸缩。

3、采用ESB减少系统中的接口耦合。

缺点:

1、系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。

2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

微服务架构：微服务架构风格以实现一组小服务的方式来开发一个独立的应用系统方法。其中每个小服务运行在独立进程。服务间通过ApiGW机制通信。

​

微服务架构图

基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等等，服务的粒度很小，所以称为微服务架构。

特点:

1、服务层按业务拆分为一个一个的微服务。

2、微服务的职责单一。

3、微服务之间采用RESTful、RPC等轻量级协议传输。

4、有利于采用前后端分离架构。

优点:

1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

2、可以更加精准的制定每个服务的优化方案，按需伸缩。

3、适用于互联网时代，产品迭代周期更短。

缺点:

1、开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。

2、微服务过多，服务治理成本高，不利于系统维护。

微服务架构2.0-Service Mesh

​

Service Mesh

优点:

1、屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控 制等等)，服务只用关注业务逻辑。

2、真正的与语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可。

3、对应用透明，Service Mesh组件可以单独升级。

缺点:

1、边缘网络，IoT场景:资源非常有限，不适合启动太多Sidecar。

2、FaaS场景:应用自身足够轻量，甚至比Sidecar还要轻量。

3、Serverless场景:ScaletoZero时，对冷启动速度有严格要求，Sidecar的启动和初始化可能拖累应用启动速度。