高并发架构设计原则-拆分

在系统设计初期，是做一个大而全的系统还是根据模块进行拆分要根据环境和需求进行权衡。

访问量不大、功能简单、研发资源不多时可以做一个大而全的系统即可；如果访问量大资源充足、功能繁多可以考虑按功能拆分系统。

下面几种拆分维度

系统维度

按照系统功能/业务拆分，比如商品系统、购物车系统、结算系统、订单系统等。

功能维度

对一个系统进行功能再次拆分，比如优惠券系统可以拆分为后台优惠券创建系统、领券系统、用券系统等。

读写维度

根据读写比例特征进行拆分。比如商品系统，交易的哥哥系统都会读取数据，读的量大于写的量，可以拆分哼商品写服务，商品读服务；读服务可以考虑使用缓存提升性能；写的量太大，写的量太大时，需要考虑分库分表；有些聚合读取的场景，如商品详情页，可以考虑数据源异构拆分系统，将分散在多出的数据聚合到一处存储，以提升系统的性能和可靠性。

AOP维度

根据访问特征，按照AOP进行拆分，比如商品详情页可以分为CDN，页面渲染系统；CDN就是一个AOP系统。

这里简单说下AOP（切面）维度的理解，AOP编程(面向切面编程Aspect Oriented Program)与OOP(Object Oriented Programming)编程相对应，我们可以简单的理解AOP编程(实际会更丰富)：代码运行时，动态的将特定代码切入到指定类的方法、指定位置上的编程思维。如果说面OOP向对象编程是一个平面横向把一个个类区分开，AOP面向切面则是对OOP的一个很好的补充，纵向上增加了时间维度，代码三维立体了。AOP在OOP中通过代理机制实现。那么什么是AOP维度的架构呢？不同请求再在用系统资源的时候，可以把系统资源进行拆分，如静态资源放到CDN或Nginx等，实现服务资源的立体化（不同资源由不同服务提供，代码链路上一一收集资源最终返回给客户）。

模块维度

按照基础代码维护特征进行拆分，如基础模块分库分表、数据库连接池等，代码结构按照三层架构（Web、Service、DAO）进行划分。（拆分颗粒需进一步探究）