没有最好的，只有最合适的。以下仅为参考！

---

一般引入分布式，是为了构建两个重要的能力。下面的描述相当于单体项目的调整（或演变）过程：


### 1、构建可水平扩展的计算能力

##### a) 服务去状态化

* 不要本地存东西
  * 如日志、图片（当多实例部署时，不知道去哪查或哪取?）
  * //可以使用 Solon Cloud File、Solon Cloud Log 和相关的中间件
* 不要使用本地的东西
  * 如本地配置（当多实例部署时，需要到处修改、或者重新部署！运维都不知道开发配了什么）
  * //可以使用 Solon Cloud Config 和相关的中间件

##### b) 服务透明化

* 建立配置服务体系
  * 在一个地方任何人可见
  * 修改后，即时热更新到服务实例或者重启即可
  * 包括应用配置、国际化配置等...
  * //可以使用 Solon Cloud Config、Solon Cloud I18n 和相关的中间件
* 建立链路日志服务体系
  * 让所有日志集中在一处，并任何人方便可查
  * 让输出输出的上下文成为日志的一部份，出错时方便排查
  * //可以使用 Solon Cloud Trace、Solon Cloud Log 和相关的中间件
* 建立跟踪、监控与告警服务体系
  * 哪里出错，能马上知道
  * 哪里数据异常，能马上知道
  * 哪里响应时间太慢，马上能知道
  * //可以使用 Solon Cloud Trace、Solon Cloud Metric 和相关的中间件

> 完成这2点，分布式和集群会比较友好。

##### c) 容器化弹性伸缩

* 建立在k8s环境之上，集群虚拟化掉，会带来很大的方便


### 2、构建可水平扩展的业务能力

//可以使用 Solon Cloud Event 和相关的中间件

##### a) 基于可独立领域的业务与数据拆分

比如把一个电商系统拆为：

* 用户领域系统
* 订单领域系统
* 支付领域系统

各自独立数据，独立业务服务。故而，每次一块业务，都不响应旧的业务。进而水平扩展

##### b) 拆分业务的主线与辅线

比如用户注册行为：

* 用户信息保存 [主线]
* 注册送红包 [辅线]
* 检查如果有10个人的通讯录里有他的手机号，再送红包[辅线]
* 因为与电信合作，注册后调用电信接口送100元话费[辅线]

##### c) 基于分布式事件总线交互

* 由独立领域发事件，其它独立领域订阅事件
  * 比如用户订单系统与公司财务系统：
  * 订单支付完成后，发起事件；公司财务系统可以订阅，然后处理自己的财务需求

* 由主线发起事件，辅线进行订阅。可以不断扩展辅线，而不影响原有代码
  * 这样的设计，即可以减少请求响应时间；又可以不断水平扩展业务