微内核架构

微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品（原文为 product-based，指存在多个版本、需要下载安装才能使用，与 web-based 相对应）的应用。例如 Eclipse 这类 IDE 软件、UNIX 这类操作系统、淘宝 App 这类客户端软件等，也有一些企业将自己的业务系统设计成微内核的架构，例如保险公司的保险核算逻辑系统，不同的保险品种可以将逻辑封装成插件。

微内核架构包含两类组件：核心系统（core system）和插件模块（plug-in modules）。核心系统负责和具体业务功能无关的通用功能；插件模块负责实现具体的业务逻辑。

一、设计关键点

微内核的核心系统设计的关键技术有：插件管理、插件连接和插件通信

1. 插件管理

核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制

核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等

DDD架构

一、概念

1. 领域、子域

用来确定范围的，范围即边界。在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域

领域可以进一步划分成子领域，我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围

子域可以根据自身重要性和功能属性划分为三类子域，分别为核心域、通用域和支撑域

3. 核心域、通用域、支撑域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力

没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。比如认证、权限等，没有企业特点，不需要做太多的定制化

CAP理论

Consistency、Availability、Partition Tolerance

Robert Greiner（http://robertgreiner.com/about/）的文章作为基础，其中有两版解释：

第一版：对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束。

第二版：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。这里的共享数据的节点集合指的是同一份数据在多个节点都有，但并不一定在所有节点都有。

对比两个版本的定义，有几个关键的差异点：

FMEA 方法-排除架构可用性隐患

FMEA（Failure mode and effects analysis，故障模式与影响分析）FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响

在架构设计领域，FMEA 的具体分析方法是：

• 给出初始的架构设计图
• 假设架构中某个部件发生故障

高可用存储架构-双机架构

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。对一个高可用存储方案，需要从以下几个方面进行思考和分析：

• 数据如何复制？
• 各个节点的职责是什么？
• 如何应对复制延迟？

高可用存储架构：集群和分区

一、数据集群

集群就是多台机器组成在一起形成的一个统一的系统，数量上至少是3台。根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群

1. 数据集中集群

也可以将数据集中集群称为1主多备或1主多从。数据只能往主机中写。

难点在于：

如何应对接口级的故障

接口级故障的典型表现就是，系统并没有宕机、网络也没有中断，但业务却出现问题了，例如业务响应缓慢、大量访问超时和大量访问出现异常（给用户弹出提示“无法连接数据库”）

这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。最常见的情况就是，数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库、要么超时，最终用户看到的现象就是访问很慢，一会儿访问抛出异常，一会儿访问又是正常结果。

导致接口级的故障的原因可以分为两大类：

• 内部原因：包括程序BUG 导致死循环，某个接口导致数据库慢查询，内存泄露等

业务高可用的保障：异地多活架构

异地就是指地理位置上不同的地方；多活就是指不同地理位置上的系统都能够提供业务服务

判断一个系统是否符合异地多活，需要满足两个标准：

• 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。
• 某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务。

如何设计计算高可用架构

计算高可用的本质是通过冗余来规避部分故障的风险，所以计算高可用的设计思想：通过增加更多服务器来达到计算高可用

计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行

关键点：

1. 哪些服务器可以执行任务。

单服务器高性能模式：Reactor与Proactor

IO 复用技术的两个关键点：

• 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须在轮询所有连接，常见的实现：select、epoll、kqueue 等
• 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理