互联网总体架构设计

1.架构完整解决方案：

1）具体业务场景

2）架构如何选型

3）架构如何设计

4）架构如何折中

5）架构线上问题如何解决

附：架构背后哲学思考

为什么要这样设计

其它方案为什么不优雅

架构的实践

拒绝空理论，空概念

实际项目架构落地经验

拒绝忽悠

2.互联网发展三阶段

1）互联网发展的三个阶段的特点：静态化，动态化，万物乱接，容易理解

3.单体架构设计

适应场景：

1）业务简单，功能不复杂

2）创业公司初期，研发人员较少的项目

3）性格要求极其苛刻

单体架构的优点：

1）容易开发

2）容易测试

3）容易部署

4）容易扩展

单体架构的缺点：

1）系统耦合性高

2）技术选型单一

3）开发效率越来越低

架构破局：

1）垂直方向拆分（业务维度）例如用户模块，订单模块，商品模块

2）水平方向拆分（功能维度）垂直拆分后，用户模块依然是一个单体，在功能上继续拆分，网关层，业务逻辑层，数据访问层，数据库怎么拆，架构就怎么拆

3）如果单体架构承载不了更高的压力怎么办？可以使用nginx做反向代理，基于不同负载均衡策略把请求压力发送到其它单体应用上。单体架构的应用是一个war包部署在tomcat上，扩展只需要再高一台机器使用Tomacat部署war包就可以了。

04 水平分层架构设计与实践
水平方向物理分为多个进程，每层逻辑解耦

网关层
业务逻辑层
数据访问层
数据存储层

水平分层架构拆分的设计原则

1）单独的页面展示服务

2）单独的网关服务

3）单独的业务逻辑服务

4）单独的数据服务

5）根据系统职能单独划分服务（类似公司职能部门划分一个道理）

任意两层之间加入消息队列都可以从同步变为异步，每层和消息队列都是同步的。消息队列的高效来源于本身的顺序写入。

业界主流的网关开源组件，没有最好，只有更合适。

业务逻辑层应该具备的基本功能

1）业务逻辑判断

2）根据不同逻辑判断实现不同功能

数据访问层应该具备的基本功能

1）CRUD 业务增删改查接口

2）ORM框架

3）Sharding支持分库分表

4）屏蔽底层存储库的差异性（redis/mysql/mongodb）

5）针对以上功能的聚合可以使用NewSql替代

同步架构

异步架构

通过引入MQ消息中间件实现分层的异步处理，提升系统吞吐量

异步目的：提升吞吐量

异步方式：消息队列

适用场景一：请求类型（读请求不可以，写请求可以）

适用场景二：业务类型（充值场景低并发用同步，社交场景并发异步）

水平分层架构的设计事项

设计过多

1）请求路径边长

2）平均响应延迟变高

3）定位问题变的复杂化

4）运维成本增加

设计过少

和单体架构基本类似

设计合理适中

同步架构（四层）
- 网关层
- 业务逻辑层
- 数据访问层
- 数据存储层
异步架构（五层）
- 网关层
- 异步消息队列层
- 业务逻辑层
- 数据访问层
- 数据存储层

以上两种架构也存在严重的问题：部分层粒度过粗，如业务逻辑层包含了所有的业务逻辑。

即便使用了水平分层架构，也还是存在缺点的，这样的分层方式还是粒度过粗，我们看看最后水平分层架构的全貌图

真正的APP请求第一步是经过DNS的，DNS通过域名获IP，去请求静态接口和动态接口的数据。静态的资源如CSS、图片是放在CDN上的，通过阿里、腾讯、百度的CDN获取静态图片，如果请求的静态资源在CDN上没有命中，CDN会请求Nginx，Nginx会把静态资源返回给CDN，CDN会把静态资源缓存起来再返回给APP，Object Store（对象存储）同理，常用的对象存储是阿里的Fastdfs和Ceph，规模比较小的话建议用Fastdfs，规模比较大的话，建议用Ceph，但是Ceph会给运维团队增加很大的压力，

05 面向服务架构设计与实践

58同城的简化模型图：

为什么SOA不是微服务架构，因为它仅仅做了一个垂直拆分。所以缺点也很明显：

每个服务还是单体架构
对ESB严重依赖

微服务架构设计与实践

服务网格架构设计与实践

参考服务网格 Pattern: Service Mesh

应用程序A部署在一台机器上，同样的sidecarA也同样部署在这样机器上，sidecarA是基础设施组件，其实现了服务发现，配置管理，熔断限流，各种服务治理的功能，这使得应用程序不用再关注服务治理的相关编码实现，只需要注重业务编码的实现，关注点拆分（而在微服务架构中是需要同时兼顾考虑的）。打个比方需要修重试策略，修改注册中心，修改服务调用路由规则，这些在微服务架构中需要修改应用编码重新部署才能生效，而在服务网格架构中只需要修改技术设施组件，在不影响业务功能代码的情况下进行修改发布升级。

下图是一个服务网格架构图：