系统架构设计-系统拆分

为什么要拆分

最开始所有业务都是在一个系统里面的，系统做大了后必然走向拆分的趋势，因为一个大力士无法完成成千上万的普通人所能做的一件大事。

如何拆分？

1. 业务拆分，将一个大系统拆成几个小系统。（拆分应当具有的最基本条件是高内聚、 低耦合的条件，也就是说，这个系统和外部系统的调用模块对于整个系统的模块来讲是比较少的，而不是大部分模块都是在和外部系统交互，除了专门用于处理系统交互的系统外，这样的拆分设计是肯定不合理的，因为通信的代价远远大于本地JVM的代价。）
2. 不做拆分，而是将系统做集群，分摊压力。
3.  独立工具、模块、服务的独立化和集群化，基于SOA服务的企业级应用，很多模块经过抽象后，并非子系统，而是一个独立的服务系统，不参与业务，只参与一个技术级别的功能服务，如MQ、JMS、MemCached等，我们经常也管这一类叫做中间件，也就是平台没有提供自己来做或第三方提供的中间件（当然中间件也包含应用服务器）。(其实这种拆分和第一种拆分有相似之处，几乎可以算是一样的拆分模式，不过说到工具化、模块化、服务化、集群化，这种属于更为专业的拆分，第一种拆分的依据是系统各项压力上来，为考虑扩展性，而不得不拆分系统，而将很多高内聚、低耦合的系统拆分出来，也就是模块成为了子系统。而这种拆分是一种技术独立性拆分，将很多较为复杂，不好解决的技术以及工具特征独立出来，虚拟化为一种服务模式，为外部提供服务，你可以将它理解为一个传统的子系统，不过它是属于很多系统里面都需要的一个公共子系统，而前者仅仅一般只为自己的兄弟模块提供相应的服务以及一些自己的对外用户服务)
4. 数据库拆分，数据库拆分是也是因为压力上升，以及存储容量的需求，最终在成本上认为拆分是必然的走势；数据库拆分有多重规则存在。
5. 由于上述各类拆分导致的运维的困难，在数以万计的计算机集群下，如何动态资源分配和拆分以及抛开分布式的内部细节来编程，如何自动化运维系统就是大型计算机集群下需要考虑的问题-云存储与云计算。

拆分会遇到哪些问题？

1. 负载均衡器的问题。
2. 不同系统之间的通信问题。
3. 数据写入和查找的问题。
4. 跨数据库事务问题。
5. 跨数据库序列问题。
6. 不同应用的本地缓存问题。
7. 系统之间的直接依赖和间接依赖问题。
8. 独立模块面临的单点问题。
9. 各类批量分组、切换、扩展的问题。
10. 统一监控和恢复问题。

 数据切分原则

1. 能不切分尽量不切分
2. 切分一定要选好合适的切分规则，提前规划
3. 数据切分尽量通过数据冗余，或表分组降低跨库join的可能
4. 业务读取尽量少用多表跨库join