01概述

2019-03-10 本文已影响0人 Fix12138

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

基础设施
网络代理