架构之道：架构、结构、中间件、安全性

对本篇文章中有些此不是很理解的，可以看之前讲解的后端通用技术大全：后端技术大全-CSDN博客一起食用，效果更加。

一、架构到底是什么

关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。

硬是要给一个概述，架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。

架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。

来看一下维基百科对架构的解释：

软件架构：是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对像。

软件架构师：软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

按照维基百科的解释：软件架构实则是各个组件的互相搭配和组件之间的相互配合，是抽象的高层事务的的逻辑流程。简单来说架构就是各个系统组件如何通讯、协调、以及控制操作的逻辑。

可以类比人体的结构来举个简单的例子来理解就是：人体是由心肝脾肺胃、耳鼻嘴等多个重要器官组成，各个器官各司其职，它们之间相互配合共同维持人的正常生活。这里的心、胃等就是整个人体架构的组件，血液就是数据,血管就是传输数据的媒介，人的皮肤和长相就是用户的界面风格，逻辑组织就是食物要首先进入胃去消化然后才会进入大肠，而不是进入肾脏。

按照这个解释，使用的kafka、redis、ssm、rabbitmq、xxljob等都是组件，这些组件各有各的作用，各自承担自己的责任去共同完成整个系统的高效流转。

1.1为什么需要架构？

有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件都需要设计和架构。

《系统架构：复杂系统的产品设计与开发》里面的一句话：结构良好的创造活动要优于毫无结构的创造活动。

与之相对应的，现在很多敏捷思想提倡 no design，只要 work 就好。期待好的架构可以在迭代中自然涌现。这个想法有点太理想化了，在现实中，只要能 work 的代码，工程师是很少有动力去重构和优化的。

1.2架构师的职责

作为架构师，最重要的价值应该是“化繁为简”。但凡让事情变得更复杂，让系统变得更晦涩难懂的架构都是值得商榷的。
架构师的工作就是要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，使哪些系统不再那么难懂。应该努力构建易懂的架构，使得在系统上工作的其他人员（例如设计者、实现者、操作员等）可以较为容易地理解这个系统。

1.3软件架构

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。
软件架构的核心价值应该只围绕一个核心命题：控制复杂性。他并不意味着某个特定的分层结构，某个特定的方法论（贫血、DDD 等）。

1.4软件架构分类

在介绍应用架构之前，先来看一下软件架构的分类。
随着互联网的发展，现在的系统要支撑数亿人同时在线购物、通信、娱乐的需要，相应的软件体系结构也变得越来越复杂。软件架构的含义也变得更加宽泛，不能简单地用一个软件架构来指代所有的软件架构工作。将软件架构划分为：

业务架构

由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。例如，阿里巴巴在没有中台部门之前，每个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688 等各有一套体系结构。而后，成立了共享平台事业部，打通了账号、商品、订单等体系，让商业基础实施的复用成为可能。
应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。

分布式系统架构

分布式系统基本是稍具规模业务的必选项。它需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP（Consistency，Availability，Partition tolerance）之间进行权衡。
数据架构：对于规模大一些的公司，数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准，是数据架构需要关注的问题。其目的就是统一数据定义规范，标准化数据表达，形成有效易维护的数据资产，搭建统一的大数据处理平台，形成数据使用闭环。
物理架构：物理架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。
运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

分层架构

分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构如下图所示：

CQRS

CQS(Command Query Separation，命令查询分离)，最早来自于 Betrand Meyer（Eiffel 语言之父，OCP 提出者）提出的概念。其基本思想在于，任何一个对象的方法可以分为两大类：
命令(Command): 不返回任何结果(void)，但会改变对象的状态。
查询(Query): 返回结果，但是不会改变对象的状态，对系统没有副作用。

六边形架构

六边形架构是 Alistair Cockburn 在 2005 年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下，而是变成了内部和外部（如下图所示）。

六边形架构又称为端口-适配器架构，这个名字更容器理解。六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。
适配器分为两种类型（如下图所示），左侧代表 UI 的适配器被称为主动适配器（Driving Adapters），因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器，被称为被动适配器（Driven Adapters），因为它们只会对主适配器的操作作出响应。

洋葱圈架构

洋葱架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换，可以一定程度地避免技术、工具或者供应商锁定。
不同的是洋葱架构，在企业应用中存在着不止两个层次，它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次（Application，Domain Service，Domain model，Infrastructure 等）。
另外，它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利，这样可以使用 mock 代替它们方便测试。

在洋葱架构中，明确规定了依赖的方向：
外层依赖内层
内层对外层无感知

COLA 应用架构

COLA 架构是自主研发的应用架构，目前已经开源。在 COLA 的设计中，充分汲取了经典架构的优秀思想。除此之外，补充了规范设计和扩展设计，并且使用 Archetype 的方式，将架构固化下来，以便可以快速的在开发中使用。
COLA 开源地址：https://github.com/alibaba/COLA
1. 分层设计
COLA 的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示，左边是传统的分层架构，右边是 COLA 的分层架构。

其每一层的作用范围和含义如下：
1）展现层（Presentation Layer）
负责以 Rest 的格式接受 Web 请求，然后将请求路由给 Application 层执行，并返回视图模型（View Model），其载体通常是 DTO（Data Transfer Object）。
2）应用层（Application Layer）
主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层。
3）领域层（Domain Layer）
主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理.
4）基础实施层（Infrastructure Layer）
主要包含 Tunnel（数据通道）、Config 和 Common。这里使用 Tunnel 概念来对所有的数据来源进行抽象，这些数据来源可以是数据库（MySQL，NoSql）、搜索引擎、文件系统、也可以是 SOA 服务等；Config 负责应用的配置；Common 是通用的工具类。
2. 扩展设计
对于只有一个业务的简单场景，对扩展性的要求并不突出，这也是为什么扩展设计常被忽略的原因，因为大部分的系统都是从单一业务开始的。但是随着业务场景越来越复杂，代码里面开始出现大量的 if-else 逻辑。此时除了常规的策略模式以外，可以考虑在架构层面提供统一的扩展解决方案。
在扩展设计中，提炼出两个重要的概念，一个是业务身份，另一个是扩展点。
业务身份是指业务在系统唯一标识一个业务或者一个场景的标志。在具体实现中，使用 BizCode 来表示业务身份，其中 BizCode 采用类似 Java 包名命名空间的方式。例如，可以用 “ali.tmall” 表示阿里天猫业务，用 “ali.tmall.car” 表示阿里天猫的汽车业务，而用 'ali.tmall.car.aftermarket' 代表这是阿里天猫的汽车业务的后市场场景。
每个业务或者场景都可以实现一个或多个扩展点（ExtensionPoint），也就是说一个业务身份加上一个扩展点，可以唯一地确定一个扩展实现（Extension）。而这个业务身份和扩展点的组合，将其称之为扩展坐标（ExtensionCoordinate），如下图所示。

这样，通过业务身份+扩展点，就可以从框架层面实现对不同租户，不同业务，不同场景的扩展定制了。整个阿里业务中台正是基于这个思想，实现的多业务支撑的。
3. 规范设计
任何事物都是规则性和随机性的组合。规范的意义就在于可以将规则性的东西固化下来，尽量减少随心所欲带来的复杂度，一致性可以降低系统复杂度。从命名到架构皆是如此，而架构本身就是一种规范和约束，破坏这个约束，也就破坏了架构。
COLA 制定了一些列的规范：包括组件（Module）结构、包（Package）结构、命名等。
比如对于组件，要求使用 COLA 的应用都应该遵循如下图所示的组件划分：

4. COLA 架构总览
在架构思想上，COLA 主张像六边形架构那样，使用端口-适配器去解耦技术细节；主张像洋葱圈架构那样，以领域为核心，并通过依赖倒置反转领域层的依赖方向。最终形成如下图所示的组件关系。

换一个视角，从 COLA 应用处理响应一个请求的过程来看。COLA 使用了 CQRS 来分离命令和查询的职责，使用扩展点和元数据来提升应用的扩展性。整个处理流程如下图所示：

应用架构的核心
纵观上面介绍的所有应用架构，可以发现一个共同点，就是“核心业务逻辑和技术细节分离”。

是的，六边形架构、洋葱圈架构、以及 COLA 架构的核心职责就是要做核心业务逻辑和技术细节的分离和解耦。
试想一下，业务逻辑和技术细节糅杂在一起的情况，所有的代码都写在 ServiceImpl 里面，前几行代码是做 validation 的事，接下来几行是做 convert 的事，然后是几行业务处理逻辑的代码，穿插着，需要通过 RPC 或者 DAO 获取更多的数据，拿到数据后，又是几行 convert 的代码，在接上一段业务逻辑代码，然后还要落库，发消息…..等等。
再简单的业务，按照上面这种写代码的方式，都会变得复杂，难维护。
因此，应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑可以反映领域模型和领域应用，可以复用，可以很容易被看懂。让技术细节在辅助实现业务功能的同时，可以被替换。

二、常用的架构技术

2.1 分布式

分布式：将同一套业务代码按照业务功能或者自定义的维度拆分不同的子系统，各个系统分开部署，每个子系统叫做服务,每个服务之间一般通过rpc或者webservice来调用

2.1.1 分布式的优点

分布式的好处就是解耦了原系统，从而便于运维部署和水平扩展，提供软件的伸缩性，甚至服务可以通过不同的语言来实现。各个模块交给不同的人员去开发，每个人各司其职，出现问题也可以快速定位

2.1.1 分布式的缺点

分布式也并不是毫无缺点的，存在以下的问题：

①：服务调用通过网络来调用，一般微服务之间使用rpc来调用的，而rpc的底层就是TCP协议，如果网络故障或者延迟高一点，那么服务调用就有出现超时的可能性，比如dubbo的话会出现RpcException

②：分布式在业务体量比较小或者粒度划分的情况下就是一种灾难式开发，开发和运维的成本都会直线上升

③：分布式的数据一致性和事务比较难以保障，业务目前使用最多的是两阶段提交2pc，需要本地事务和远程事务综合提交，性能比较差

④：分布式session的维护在单体工程中是不需要考虑session的安全性的，而在分布式环境中就必须考虑如何去维护session的一致

⑤：分布式事务问题：分布式下如何保证各个服务的数据一致性也是一种挑战，当程序出现异常崩溃的时候能够保证各个服务能够正常回滚是很重要的。

分布式最常见的技术：分布式缓存、分布式存储、分布式计算、分布式静态资源

2.2 集群

集群：同一套代码部署在多个服务器上，而多个服务器可以提供更多的cpu、内存、硬盘等资源，从而提升整理的处理请求能力。集群的每个服务器叫做节点，每个节点提供的是相同的服务，节点的关系只是一种简单的复制，具体是哪个节点处理，则是根据负载均衡策略来决定；

在网站的处理能力出现下滑的时候，简单的在集群中增加服务器台数就可以显著增加整体的数据量处理能力(不过存在上限)；

原理很简单：所谓众人拾柴火焰高，多台服务器一起聚合处理数据量和并发访问的能力肯定比单台服务器要高很多；在遇到请求处理的瓶颈时候，可以通过简单的增加服务器台数来提高并行处理的能力，不过需要注意的是增加服务器台数在出现大于某个数量之后性能会停滞不前。

2.3 缓存

缓存是提高软件的性能第一手段，最有效和最具代表性的方法，缓存分为单机缓存和分布式缓存。最常见的分布式缓存技术为redis、memorycache等，单机缓存比如hashmap、concurrentHashmap、guava等。单机缓存的承载容量有限，而分布式缓存的伸缩性和的存储容量会比较可观，就算缓存的空间不足了，也可以通过增加服务器来扩展。

缓存最显著的作用有两个：

①加快数据的访问速度

②分担后端的数据访问和存储的负载能力，保护数据库

使用缓存需要注意以下几点：

① 缓存雪崩

缓存雪崩指的是所有的缓存在统一时间全部失效，导致大量的请求直接涌入数据库，数据库被击垮。

解决缓存雪崩的方法：缓存过期值在一定的基础上设置随机值

② 缓存击穿

缓存击穿是指某些热点key在某一时间全部失效了，导致大量的请求涌入后台DB数据库，解决缓存击穿的方法：热点数据设置永不过期

③ 缓存穿透

一直请求不存在的数据，最终走的还是数据库就是缓存穿透

解决缓存穿透的方法：采用布隆过滤器(bloomFilter)，布隆过滤会有一定的误差，但是可以晒选出一定不存在的数据，缺点是无法判定某个key是否确定存在。

2.4 队列

试想这样一个的高请求量场景：各大电商的双11，在双11的那一刻，有大量订单涌入，后端会接受请求，然后写入数据库，等待数据库的返回。如果请求量非常大的话，数据库读写IO就会阻塞，那么程序就会出现卡死，数据库崩溃等问题。

如果采用队列的话，将下单请求发送到队列中，然后立刻返回(可以按照业务决定，比如返回处理中，等到真正成功再通知用户)，这样就不需要等待后端必须返回成功。消费端可以按照请求的顺序平滑的去消费，缓解了高峰的请求，并且实现了请求下单和实现下单的解耦。从以下图可以看出使用队列以后处理起来比较平滑~

2.5 多线程

多线程真正的意义有两个①提高cpu的利用率 ②：加快程序执行效率，目前已经是多核的时代，服务器六核、八核屡见不鲜，在多核的cpu中如果使用单线程那么无疑是对多核cpu的浪费，多线程能够有效提高cpu利用的效率，多个任务分给多个cpu去处理，可以实现真正的并行处理。

如果在单核cpu中，只是cpu在不停的切换cpu时间。假设有十个表格的数据需要分析处理(计算密集型)，采用单线程需要一个个的轮询表格，而多线程在合理分配线程数的情况下就可以同时处理，提高开发的效率

2.6 限流

限流是面对高并发的利器之一，例如秒杀场景：在大量的请求涌入后台，QPS高达几十万，如果不能做到有效控制就可能导致请求击垮数据库，DB基本上是一个网站的命脉。缓存、队列、限流等方式的本质其实都是为了保护DB。限流的简单理解其实就是过滤掉无效的请求，将请求限制在一个可以控制的范围内，最常见的限流有以下方式：

① Redis限流

Redis限流的基本思路是采用redis的key过期策略，将业务id和业务值放入到redis中设置一定的过期时间，等请求再次进入的时候，如果能从redis获取到值，那么就因为是重复性请求。Redis过滤限流是最基础的限流手段，适用于过滤同一个用户请求的场景

② 令牌桶算法

令牌桶算法的思路是在一定的时间内生成以固定的速度生成有限个令牌数量放入桶中，所有的请求首先从令牌桶中去尝试获取令牌，如果能获取到就可以继续执行，否则请求就会被抛弃。Google开源的guava中有RateLimter可以实现单机限流，令牌桶算法是限流非常有效的手段。

③ 漏桶算法

漏桶算法的基本原理是将请求直接存放在一个漏斗中，请求过多的话，那么就会漏斗就会溢出，溢出的请求则会被拒绝服务。漏桶算法可以控制端口的流量输出速率，平滑请求的突发流量，实现流量整形。

因为漏桶算法的漏出速率是有效的，因此漏桶算法相比于令牌桶算法有一个显著的缺点是无法应对突发性的流量。可令牌桶算法是可以的

④ 滑动窗口

http为了控制流量的速率采用的方法就是滑动窗口机制。如果要分布式限流，可采用阿里的Sentinel框架，其基本原理是滑动窗口机制，利用Entry映射资源来平滑的限流

此外还有nginx限流，比如使用参数来限制某一个ip的在时间范围内的访问频率。客户端限流：发起请求按钮点击后，在后面的几秒内(由业务决定)设置为disabled，这一操作步骤虽然很小，但是带来的限流作用很可观

2.7 服务降级和熔断

很多人会忽视这个问题，对自己设计出来的架构盲目自信，认为不可能出问题。而事实上，一旦随着微服务和分布式架构的持续推进，服务器会越来越多，宕机的概率和可能性会逐步提升，虽然出现宕机的可能性基本上很渺茫，不过也应该做好服务降级和熔断的准备，以防止那万分之一的概率宕机。假设有1000台服务器发生宕机的概率是0.001%，就因为存在0.001%的概率会导致服务并非100%高可用。

服务的降级和熔断一般采用的是netfly(没错，就是那个美剧巨头公司)出的hystrix，可以实现服务熔断和降级