01互联网发展的三个阶段

PC互联网->移动互联网->物联网
在这个过程中：

• 业务功能越来越复杂
• 数据量越来越大
• 请求量越来越大，更高的用户体验要求
• 业务快速迭代和持续交付能力的需求

02 互联网架构演进之路

根据用户访问量和数据量等需求的发展，架构从单体发展出了水平拆分和面向服务的架构。随着业务快速迭代和持续交付能力的需求，发展出了微服务架构和服务网格架构。

单体架构
水平分层架构 / 面向服务架构
微服务架构
服务网格架构

03 单体架构

04 水平分层架构设计与实践

水平分层架构

App/Client->Nginx->网关层->消息队列（可选）->业务逻辑层->数据访问层->数据库

网关层

网关层的主要功能包括：

• 请求鉴权：发布商品，登录鉴权
• 数据完整性检查：数据包定长Header+变长Body
• 协议转换：JSON->HashMap(String, Object)
• 路由转发：根据CMD转发到不同的业务逻辑层
• 服务治理：限流、降级、熔断等

常见的网关类解决方案：

image.png

数据访问层

数据访问层的功能包括：

• 根据业务对数据库进行CRUD
• ORM（如MyBatis等）
• 分库分表（Sharding-JDBC）
• 屏蔽底层存储差异性（比如MySLQ/MonogDB/Redis等，当底层数据库类型切换时，只要对数据访问层修改即可，业务逻辑层保持不变）

同步架构和异步架构

异步架构通过在架构中添加消息队列来实现。消息队列一般加载网关层和业务逻辑层之间。消息队列带来的好处包括：

• 异步，加快请求的返回
• 解耦，降低各个业务模块之间代码耦合
• 削峰，将流量峰值缓存在消息队列中，避免瞬时高并发量击垮底层服务

水平分层架构缺点

• 请求路径变长
• 平均响应延迟变高
• 定位问题变得复杂化
• 运维成本增加

05面向服务架构设计

SOA（Service-Oriented Architecture，面向服务的架构），其特点是根据业务，进行垂直拆分。每个服务还是一个单体架构，强依赖于ESB(Enterprise Service Bus，企业服务总线)

06微服务架构设计与实践

微服务架构的本质是从两个维度拆分系统：

• 业务架构
• 组织架构
  达成的目的：
• 项目快速迭代
• 项目持续交付
  架构缺点：
• 关注业务代码需要关注服务间注册发现通信等问题，导致业务迭代速度变慢
• 基础设施组件升级困难，因为类似注册发现机制都是通过jar引入业务工程的，基础设施组件升级需要业务方配合，代价大。

07服务网格架构

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

• 基础设施
• 网络代理

image.png

服务网络架构有点：

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

业界框架：

• Linkerd，来自Buoyant公司，Scala语言，Service Mash名词的创造者
• Conduit，来自Buoyant公司，Rust语言
• Envoy，来自Lyft公司，基于C++
• Nginmesh，来自Nginx公司，基于Go，兼容Istio
• Istio，来自Google，IBM，Lyft公司，基于Go/C++，Service Mash集大成者