单体项目如何演变成分布式架构
- 1、单体架构
- 1.1、领域驱动设计，业务驱动框架
- 1.2、根据MVC模式，内部划分业务模块
- 1.3、根据业务模块，内部划分MVC
- 2、分布式思路
- 2.1、分布式优点
- 2.2、分布式架构前期
- 2.3、分布式中期
- 3、长连接服务器
- 3.1 具体实现
- 3.2 待确定问题
前言：
由于公司刚开始是一个初创公司，所以项目是单体项目。但随着业务的增多，性能的消耗，导致单体项目无法继续支撑，于是就简单的出了一个单体拆分成分布式架构的一个流程。
中间也踩了很多坑，但最多的坑，和花时间最多的地方，是在于前期单体项目时候，不规范导致的问题。所以哪怕是单体项目，也要规划好。
1、单体架构
我们在做单体架构的时候就要划分业务的边界
1.1、领域驱动设计，业务驱动框架
1.2、根据MVC模式，内部划分业务模块
这种优点是，业务透明，一目了然
1.3、根据业务模块，内部划分MVC
这种优点是：层级清晰，逻辑严谨。这样的包设计与后期微服务拆分有良好的匹配度，易迁移变动小。
整体来说：未雨绸缪，在做单体架构的时候，就理清业务边界问题，后面流量、数据量上来后，降低水平扩展的难度。
但是缺点：需要具备良好的编码风格才能有效的执行。
2、分布式思路
2.1、分布式优点
- 将大而全的单体项目，根据业务单元，拆分成独立的服务
- 相互调用，相互依存
- 全链路测试、追踪
- 职责单一、分工明确、易于理解和维护
- 低耦合，服务之间影响小
- 可独立扩容成集群
- 独立开发，独立部署
2.2、分布式架构前期
- 服务器集群模式
8.1 Nginx负载均衡 - 数据库
9.1 读写分离
9.2分库分表
9.3水平拆分
9.4垂直拆分 - 业务上依据二八原则，水平拆分
- Redis缓存
11.1缓存雪崩
11.2缓存穿透
11.3缓存击穿 - 分布式事务
12.1数据库层面
12.2 引入2PC或者3PC
12.2 业务层面
12.3 TCC
12.4 消息事务
12.5 本地消息表 - 服务通讯
13.1 RPC
13.2 消息中间件
2.3、分布式中期
- 微服务框架
15.1 监控
15.2 链路追踪
15.3 网关
15.4 动态扩容：Zookeeper、Etcd、Eureka - Docker容器
3、长连接服务器
3.1 具体实现
消息推送
多人互动
社交聊天
实时同步
3.2 待确定问题
消息过滤：推送消息时，如何过滤掉下线的客户端
消息管理：和客户端合理设计好数据格式
消息延迟：广播时，如果在线人数过多，如何保证第一条消息和最后一条消息的延迟差
人数上限：如果人数过多导致服务器和业务层消息通道瓶颈，该如何处理，到时是否需要引入消息队列
