架构设计

1. 软件模块：是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
2. 软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
3. 从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。其实，“组件”的英文component也可翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。
4. 系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
5. 软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
6. 软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。参考维基百科的定义，将架构重新定义为：软件架构指软件系统的顶层结构。这个定义看似很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，我来详细解释一下。

首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。

其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

第三，维基百科定义的架构用到了“基础结构”这个说法，我改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。

1. 软件的复杂度
   1. 高性能

线程是任务调度的最小单元，共用进程内的资源。

进程是资源分配的最小单元，与其他进程资源互相独立

1. 1. 高可用，系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。无论是计算高可用还是存储高可用，其基础都是“状态决策”，即系统需要能够判断当前的状态是正常还是异常，如果出现了异常就要采取行动来保证高可用。如果状态决策本身都是有错误或者有偏差的，那么后续的任何行动和处理无论多么完美也都没有意义和价值。但在具体实践的过程中，恰好存在一个本质的矛盾：通过冗余来实现的高可用系统，状态决策本质上就不可能做到完全正确
      1. 独裁式
      2. 协商式
      3. 民主式 zookeeper 缺点是脑裂
   2. 可扩展性
   3. 低成本
   4. 安全
   5. 规模
2. 架构设计三个原则
   1. 合适原则，合适原则宣言：“合适优于业界领先”
   2. 简单原则，简单原则宣言：“简单优于复杂”。软件领域的复杂性，体现在两个方面：
      1. 结构的复杂性，结构复杂的系统几乎毫无例外具备两个特点：
         1. 组成复杂系统的组件数量更多
         2. 同时这些组件之间的关系也更加复杂
      2. 逻辑的复杂性
   3. 演化原则，演化原则宣言：”演化优于一步到位”
3. 架构设计流程
   1. 识别复杂度
      1. 构建复杂度的来源清单—高性能 可用性 扩展性 安全 低成本 规模
      2. 结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键
      3. 得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键
   2. 设计备选方案，架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。常见的错误：
      1. 设计最优秀的方案
      2. 只做一个方案
      3. 备选方案过于详细
   3. 评估和选择备选方案
      1. RocketMQ和kafka有什么区别
         1. 使用场景：kafka适合日志处理  RocketMQ适合业务处理
         2. 性能，kafka单机写入TPS号称在百万条/秒，RocketMQ大约在10w条/秒
         3. 可靠性，RocketMQ支持异步/同步刷盘；异步/同步replication；kafka使用异步刷盘，异步replication。RocketMQ所支持的同步方式提升了数据的可靠性
         4. 实时性，均支持pull长轮询，RocketMQ消息实时性更好
         5. 支持的队列数 kafka单机支持超过64哥队列/分区，消息发送性能降低严重；RocketMQ单机支持最高5万个队列，性能稳定
         6. Kafka没用过，但是上网看了相关对比，认为阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka不能满足或者ActiveMQ等其他消息中间件不能满足，所以选择自己开发（RocketMQ设计的真的很牛）
            1. 数据可靠性

kafka使用异步刷盘方式，异步Replication

RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication

1. 1. 1. 1. 严格的消息顺序

Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序

RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序

1. 1. 1. 1. 1. 消费失败重试机制

Kafka消费失败不支持重试

RocketMQ消费失败支持定时重试，每次重试间隔时间顺延

1. 1. 1. 1. 1. 定时消息

Kafka不支持定时消息

RocketMQ支持定时消息

1. 1. 1. 1. 1. 分布式事务消息

Kafka不支持分布式事务消息

阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息

1. 1. 1. 1. 1. 消息查询机制

Kafka不支持消息查询

RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）

1. 1. 1. 1. 1. 消息回溯

Kafka理论上可以按照Ofset来回溯消息

RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

1. 1. 详细方案设计
      1. Nginx的负载均衡策略
         1. 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，后端服务器分配的请求数基本一致，如果后端服务器“down掉”，能自动剔除。

1. 1. 1. 1. 加权轮询

根据权重来进行轮询，权重高的服务器分配的请求更多，主要适应于后端服务器性能不均的情况，如新老服务器混用。

1. 1. 1. 1. ip_hash

每个请求按访问IP的hash结果分配，这样每个访客固定访问一个后端服务器，主要用于解决session的问题，如购物车类的应用。

1. 1. 1. 1. fair

按后端服务器的响应时间来分配请求，响应时间短的优先分配，能够最大化地平衡各后端服务器的压力，可以适用于后端服务器性能不均衡的情况，也可以防止某台后端服务器性能不足的情况下还继续接收同样多的请求从而造成雪崩效应。

1. 1. 1. 1. url_hash

按访问URL的hash结果来分配请求，每个URL定向到同一个后端服务器，适用于后端服务器能够将URL的响应结果缓存的情况。