单体项目如何演变成分布式架构项目

前言：
由于公司刚开始是一个初创公司，所以项目是单体项目。但随着业务的增多，性能的消耗，导致单体项目无法继续支撑，于是就简单的出了一个单体拆分成分布式架构的一个流程。
中间也踩了很多坑，但最多的坑，和花时间最多的地方，是在于前期单体项目时候，不规范导致的问题。所以哪怕是单体项目，也要规划好。

1、单体架构

我们在做单体架构的时候就要划分业务的边界

1.1、领域驱动设计，业务驱动框架

1.2、根据MVC模式，内部划分业务模块

这种优点是，业务透明，一目了然

1.3、根据业务模块，内部划分MVC

这种优点是：层级清晰，逻辑严谨。这样的包设计与后期微服务拆分有良好的匹配度，易迁移变动小。
整体来说：未雨绸缪，在做单体架构的时候，就理清业务边界问题，后面流量、数据量上来后，降低水平扩展的难度。
但是缺点：需要具备良好的编码风格才能有效的执行。

2、分布式思路

2.1、分布式优点

1. 将大而全的单体项目，根据业务单元，拆分成独立的服务
2. 相互调用，相互依存
3. 全链路测试、追踪
4. 职责单一、分工明确、易于理解和维护
5. 低耦合，服务之间影响小
6. 可独立扩容成集群
7. 独立开发，独立部署

2.2、分布式架构前期

8. 服务器集群模式
   8.1 Nginx负载均衡
9. 数据库
   9.1 读写分离
   9.2分库分表
   9.3水平拆分
   9.4垂直拆分
10. 业务上依据二八原则，水平拆分
11. Redis缓存
    11.1缓存雪崩
    11.2缓存穿透
    11.3缓存击穿
12. 分布式事务
    12.1数据库层面
    12.2 引入2PC或者3PC
    12.2 业务层面
    12.3 TCC
    12.4 消息事务
    12.5 本地消息表
13. 服务通讯
    13.1 RPC
    13.2 消息中间件

2.3、分布式中期

15. 微服务框架
    15.1 监控
    15.2 链路追踪
    15.3 网关
    15.4 动态扩容：Zookeeper、Etcd、Eureka
16. Docker容器

3、长连接服务器

3.1 具体实现

消息推送
多人互动
社交聊天
实时同步

3.2 待确定问题

消息过滤：推送消息时，如何过滤掉下线的客户端
消息管理：和客户端合理设计好数据格式
消息延迟：广播时，如果在线人数过多，如何保证第一条消息和最后一条消息的延迟差
人数上限：如果人数过多导致服务器和业务层消息通道瓶颈，该如何处理，到时是否需要引入消息队列