应用拆分思考

以下是根据现在做的系统，做出来的如下的总结：

应用拆分基本原则

• 根据业务场景来明确划分出几个互不影响或者影响很小（仅需要提供数据）的系统。如：搜索查询、订单、账资核算等。

• 上述的每个应用本身，可以根据功能划分应用。如搜索查询需要调用外部接口，则有对应的相关的外部接口的独立应用。

• 避开事务操作跨应用，分布式事务将会是个很消耗资源的问题，应当在设计时避免。

目的：
1）应用和应用之间的耦合度降低，在一个应用挂了的情况下，其它的应用可以继续服务。
2）开发过程中，应用之间独立开发，定义好服务接口，之间的开发互不影响。

应用之间的通信

• 同步的RPC调用框架，如Dubbo、ali的HSF等

• 异步消息通知，如MetaQ

PS：
1）异步消息通知适用于一些耽搁数据包小，但是数据量大，对实时性要求不高的场景。如支付宝的转账成功等。
2）选择RPC调用框架，而不是传统的http或webservice服务的原因是，使用service方法无感知，在配置好后，和本地调用方法类似。

应用之间数据库设计

每个应用都有自己独立的数据库
1）共同使用的基础信息可以放在common库中一起使用；
2）业务相关的数据，如需使用到其它应用的业务数据，需采用同步数据的方式，这样应用之间才算真正意义上的隔离。
3）数据隔离的设计，可以防止因为数据库问题（慢查询、连接池用尽等问题）带来的整个平台“熄火”

PS：
1）定时任务方式，同步数据，势必会给系统的效率带来一定的损耗，根据业务场景需要来选择

任务分发调度

• 涉及到分布式部署系统的时候，就牵扯到任务分发调度的问题：
  1）对于前台的http请求，仍然可以采用apache等来进行请求分发。
  2）对于一些后台任务呢？一般是借助Quartz来进行任务分发。