在我们从零开始做一个新系统的时候，会首先进行系统功能模块架构设计，那么是直接做一个大而全的垂直的MVC系统，使用一个war包进行发布管理，还是需要按一些规则进行模块拆分，设计成SOA或者微服务系统比较好呢？这个笔者认为需要依据项目具有什么样的人力物力条件以及项目需要支撑多少用户量和交易量为基础。一个好的系统设计应该能够满足解决当前的需求和问题，把控实现和进度风险，预测和规划未来，避免过度设计，在上线一个基础核心版本之后，再进行不断迭代和完善。
今天我们来谈一谈进行SOA、微服务系统架构设计时模块拆分的一些维度和原则。
1. 功能维度
按照系统业务功能进行划分，例如对于电商系统，按功能维度我们可以拆分为商品中心，订单中心，用户中心，购物车，结算等功能模块。
2. 状态维度
对于一个功能模块可以按照不同的业务逻辑状态再进行划分，比如电商的优惠券模块按状态可以划分为创建模块，领券模块，使用模块。这个是从一个业务从开始到结束的不同状态进行的模块拆分。
3. 读写维度
按照读写不同的压力进行拆分，例如对于商品中心而言，读取商品详情的量会特别大，远远大于写入商品详情的量。这个时候就可以拆分为商品的写服务、读服务。读取服务可以考虑使用redis或者memcache缓存来提高性能，也可以做读写分离，而且可以依据访问需求量增加或者减少读写服务的部署数量。当写入的量太大时，可以考虑做分库分表，有些聚合读取的场景，比如商品详情页可以考虑使用数据异构，将分散的数据聚合到一个存储，从而提升系统的可靠性和性能。
4. 纵深维度
按照纵深的维度，最底层的是基础服务，最上层的是业务服务，代码结构一般按照MVC三层架构来进行划分。
5. AOP维度
根据访问特征，按照AOP进行拆分，比如商品详情页可以分为CDN、页面渲染模块等。而CDN就是一个AOP。
版权声明：本文为博主原创文章，欢迎转载。 https://blog.csdn.net/u011095110/article/details/74772807
