谈架构设计的要求

Posted 2021-06-16 小许的技术人生

一名合规的技术人员，在职业发展过程中需要培养和锻炼架构能力。今天我们聊下什么是架构，以及需要什么样的架构能力。

1. 何为架构

维基上软件架构的定义：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计，包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。

我自己的理解，架构的核心要素是：结构、约束。

结构，说的是架构定义了软件系统的整体框架和组件间的逻辑关系，就好比建房子，地基和初期设计定义了整个建筑的底座。在软件系统中，分层模式，就是软件结构的体现。

约束，表达的是软件系统的运行规则和边界条件。技术规范会约束软件的行为，防止无序扩张而不可控。

2. 架构能力

随着服务化的盛行，目前大部分系统都是处在分布式环境的。在架构设计中，掌握分布式系统理论是我们进行架构设计的前提，其中最著名的是CAP理论、BASE理论。

业务抽象

软件的本质是对业务进行建模，通过技术的抽象还原客观事务。但是，做好业务抽象是不容易的。无论是早期的UML、传统的ER理论，还是如今比较火热的领域驱动设计（DDD），都是在回答如何对业务进行还原和建模的问题。没有好的业务抽象能力，不可能设计出一个好的软件。

可扩展

在面向对象设计中有一个著名的开闭原则，要求软件系统在升级过程中尽量不修改原有的组件，而是在已有的组件上进行功能扩展。可扩展性的高低，是衡量一个软件或程序员是否优秀的标准。

面向对象中的SOLID原则和23种设计模式，是对开闭原则的进一步解释，需要深刻理解。

AFK立方体，描述了如何从三个坐标维度去构建扩展一个软件。

基于元数据驱动的设计理念，则描述的是如何设计一个高度灵活的数据库模型以满足saas系统的个性化定制需求。

一致性

分布式系统的数据一致是个难题。其分为最终一致性和强一致性。

强一致性，主要用在对数据一致很敏感的业务场景，典型的就是金融系统。分布式二阶段协议、三阶段协议就是用来实现强一致的理论基础。

最终一致性，是目前互联网系统中大多数场景的选择。主要有几个实现方式：

1. 本地消息表+异常补偿：业务数据操作和消息数据持久化在一个本地事务中，通过定时扫描消息表，可达到最终一致。

2. 消息中间件的事务消息：通过两阶段消息发送和消息中间件的本地回查，达到最终一致。

3. TCC。将事务的处理分为预提交、提交、回滚三个阶段，也可达到最终一致性。已有开源的实现方案如阿里的SETA
   

高可用

从laas层看：

最低层次的要求：集群部署，服务可伸缩，尽量无状态。

进阶的要求：考虑多集群部署，有备份，具备同城、异地容灾、甚至跨洲容灾能力

高层次的要求：异地多活。例如构建单元化环境、三地两中心多活等。
从saas和paas层看：

服务需要具备限流、降级、熔断的能力。

限流，是服务提供方将超出阈值的请求直接拒绝。

降级，是指当依赖的外部服务出现问题时，关闭部分系统功能，或将依赖下架。

熔断，是指服务出现异常时，对外部调用直接返回失败，以防系统发生雪崩。

高性能

实现高性能的方式有缓存和异步化。

缓存的使用场景非常广泛：

1. 接入层，如DNS、CDN、nginx，缓存静态页面资源或图片。

2. 计算层，如本地缓存和分布式缓存

3. 存储层，如数据库查询引擎可以开启缓存。

4. 操作系统层，如虚拟内存技术。

异步化，就是将不在主链路的功能进行解耦，可以防止业务线程的堵塞。在分布式系统中，在服务间采用消息队列的方式进行通讯和交互已经非常普遍，就是为了模块解耦。

需要注意的是，异步化往往会和多线程并发及锁竞争联系在一起。在多线程环境，一定要注意线程池的配置，如果频繁进行线程切换，反而会影响系统的吞吐量。