背景
讨论模块拆分之前，我们以电商系统为例,它包含5个模块：用户、产品、订单、配送、发票。两个端：一个是电脑版卖家端，一个是移动端买家端。
假设运行时，每个模块运行时使用1/5的资源。
以下例子中的用户量只是举例，不具有参考意义
单体模式：
当用户量为10,000时，1台服务器可能就够了。
集群模式：
当用户量为1,000,000时，100台服务器集群就可以了。
微服务模式：
当用户量为1,000,000,000（10亿）时，可能只需要20,000台服务即可，约为集群的100,000台服务器的1/5。20,000计算方式如下所示：
假设大家逛电子商城只看不买。
服务器数量=(1/5)*100,000=20,000台即可。
该计算不严谨，仅可以粗略展示节省的程序运行资源。通常，提供服务占用资源>>程序运行需要的硬件资源。
当业务量达到一定规模时候需要拆分微服务。但是模块拆分可以提前。
为什么要模块拆分？
有以下原因：
- 模块复用：公司有多个产品时，可以按照模块的颗粒度复用，如用户模块。
- 按需使用：
- 产品私有化部署时，以上文中电商系统为例，若不需要发票模块，开发和发布时可以去掉。
- 还有一些场景，一个项目包含多个产品，开发和发布时，节省的资源和时间更为明显。
- 微服务化准备。
模块拆分方式？
不拆分模块
后台部署一份服务，两个不同的前端。
优点：开发和部署简单。
按端拆分：卖家端和买家端
优点：
缺点：工作量增大，出现较多重复代码，比如每个端都有用户登录、产品查询、订单查询等，需要写两份。
按业务拆分（推荐）
优点：提高模块复用，可以按需使用，容易微服务化。
缺点：依赖复杂
五个核心模块主要写业务Service，卖家端和买家端仅仅提供对外API接口。
微服务化
优点：单个服务可以按需部署
缺点：开发和运维复杂性提升
五个核心模块不仅有Service，也提供对外API接口，卖家端和买家端是一个概念，它们在后端不存在，通过前端将它们组织起来。
