一、架构演变

1.1互联网发展三阶段

PC互联网 ------> 移动互联网 ------> 物联网（IOT）

• 互动形式
  1）互动1.0：内容在线；单一互动（一个中心对多点点广播模式）；门户网站（三大门户），企业门户网站，提供一些信息服务
  2）互动2.0：以互动为核心；产品有了“关注”，因为“关注”互动产生了网络效应，说的人越多，关注的人越多；新浪微博、Twitter等，关注的网络效应；搜索等
  3）互联3.0：群组和朋友圈，把关注一对一的关系，变为更广泛的多对多的关系，形成了真正的互联网形态，人越人联系的更加紧密；微信，facebook，让我们互联，新诞生的一些具有影响力的名词，群主，朋友圈等

• 发展特点
  1）业务功能越来越多，越来越复杂
  2）万物互联，数据量越来越大
  3）请求量越来越多，需要更好的更高的用户体验需求
  4）业务持续快速迭代交付的能力

1.2互联网架构演进之路

单体架构------> 水平拆分跟面向服务架构------ >分布式架构 ------> 微服务架构 ------> 服务网格架构

1）单体架构设计与实践

典型的MVC结构，API层，业务层，DAO层等整合在一个war包里，进行部署
优点： 开发简单；测试简单；部署简单；规模结构简单；当业务支撑力不足时，可简单水平（横向）扩展

缺点：
系统耦合度高： 技术选型单一；开发效率越来越低下，随着业务发展，数据量增大，该如何打破僵局：
数据库层面： 有垂直拆分（分库）和水平拆分（分表
系统层面： 垂直拆分（业务维度）和水平拆分（功能维度）

2）水平分层架构设计与实践

水平分层架构是将软件系统按水平方向物理切分为多个独立进程（部署在不同的容器内），最基本的分层方式是表现层、业务逻辑领域层和数据持久层（MVC）

优点： 单一职责、高内聚、低耦合、提高可复用性和降低维护成本。
缺点： 开发成本高、不同的层次之间调用的网络消耗

网关对比：

网关作用：

• 性能：API高可用，负载均衡，容错机制。
• 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
• 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
• 缓存：数据缓存。
• 监控：记录请求响应数据，api耗时分析，性能监控。
• 限流：流量控制，错峰流控，可以定义多种限流规则。
• 灰度：线上灰度部署，可以减小风险。
• 路由：动态路由规则。

3）面向服务设计与实践

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

优点： 低耦合，跨语言，跨系统
缺点： 业务垂直拆分，每个服务还是单体，对ESB严重依赖

4）微服务架构设计与实践

微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并且以轻量级机制（通常是HTTP REST API）通信。这些服务是围绕业务能力建立的，并且可以由完全自动化的部署机构独立部署。这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据存储技术。

优点： 独立缩放，独立发布与部署，独立开发，优雅降级，分散治理，持续集成和交付
缺点： 微服务中业务关注服务间“通信”，业务迭代需要多方业务支持，导致业务迭代速度慢；基础设施组件升级困难，影响交付能力和交付速度；多语言通信之间的问题，业务服务每种语言一套基础设施、成本大

5）服务网格设计与实践

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序来说是透明的。

请求的大致过程：

1）请求： 应用程序A将req发送到SidecarA，SidecarA将req发送到SidecarB，SidecarB将req发送到应用程序B
2）响应： 应用程序B将resp发送到SidecarB，SidecarB将resp发送到SidecarA，SidecarA将resp发送到应用程序A

优点： Service Mesh独立进程、独立升级；业务团队专注于业务逻辑本身；一套基础设施支持多语言开发；业务团队和基础设施团队物理解耦

二、架构设计

2.1、高可用设计手段

高可用评价标准1： 通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%

描述	通俗叫法	可用性级别	年度停机时间
基本可用	2个9	99%	87.6小时
较高可用	3 个9	99.9%	8.8小时
具有故障自动恢复能力的可用性	4 个9	99.99%	53分钟
极高可用	5 个9	99.999%	5分钟

高可用评价标准2： 根据业务影响范围来评估，业务高或低峰期，不同时机停机对业务影响程度不同（影响请求量/总请求量）
1）服务无状态化： 服务的无状态化就是冗余部署的多个服务进程，使其完全一样。也就是部署多个相同服务，请求到任一服务的处理结果是一样的。这样当某台服务挂掉时，可以路由到其他可正常提供服务的服务器上，从而避免了由于某台服务而是服务不可用的情况出现

2）负载均衡： 通过负载均衡可以实现让请求合理的分配到不同的服务器上

3）超时机制： 设置一个超时时间，当等待的时间超过该设定值时，便不再继续等待，这样可以防止由于下游服务异常而拖累自己的服务。当然，也可以进行异步化设计，这样就不需要等待服务响应后，在进行接下来的处理，从而提系统的高吞吐量。

核心的流量采样同步来做（防止数据丢失），非核心的采用异步化来做

4）服务限流熔断降级： 服务的限流是为了保护本服务，当服务的调用量超过自己的处理能力时，就需要进行限流操作了；熔断时为了同时保护下游服务和本服务，当下游处理能力达到极限而报错时，可以通过熔断减少对下游服务对调用，与此同时有防止下游服务拖累上游服务

5）架构拆分服务治理： 架构拆分做到服务隔离，避免由于其他服务，而影响整个系统无法正常提供服务；服务治理，服务监控可以实时观察服务对异常情况，服务分级可以将优先级较低对服务先进行下线处理等

2.2、高并发设计手段

优化手段：

1）空间换时间： 缓存
2）时间换空间： 数据大小时瓶颈，那么可以对数据进行压缩
3）寻找系统瓶颈： IO瓶颈或CPU瓶颈，是数据库还是代码，数据库优化、JVM调优等

优化目的：缩短响应时间，提高吞吐量，使系统处于合理状态

2.3.、服务无状态化设计

目的： 快速扩容服务，弹性缩容服务

2.4、服务负载均衡设计

1）硬件负载： F5、A10等
2）软件负载： LVS、Nginx、HAProxy等

负载均衡算法：随机、轮询、哈希、一致性哈希、最小连接数等

2.5、服务幂等性设计

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
显然查询类等天然幂等

• 1）insert添加业务唯一索引
• 2）select天然幂等
• 3）update绝对值修改, update user set age=11 where id=1幂等，update user set age=age+11 where id=1不幂等
• 4） delete也是绝对值幂等

接口幂等设计：

• 1）通过代码业务逻辑判断实现
• 2） 使用token机制实现