微服务分解细则与要点

在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。

应用采用多层架构或者六角架构，主要由以下几类不同组件构成：

• 展现组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）
• 业务逻辑——应用的业务逻辑
• 数据库访问逻辑——用于访问数据库的数据访问对象
• 应用集成逻辑——消息层，例如基于Spring Integration

不同逻辑组件分别响应应用中的不同功能模块。

1.拆分原则

• 单一职责
• 服务粒度适中
• 考虑团队结构
• 以业务模型切入
• 演进式拆分
• 避免环形依赖和双向依赖

2.拆分过程

1. 对整个平台按业务和功能进行多模块拆分

2. 分离出通用组件，把相关的类重构到一个包里，export成一个common_package共享使用

3. 对每个固定模块的功能进行业务范围限定， 界定功能适用范畴边界，比如数据、资源的管理

4. 处理方式，按功能尽量标准化、规范化输入&输出，形成服务内部的分离

   1）自身独有的基础功能 eg: 实体的增、删、改、查

   2）与其他服务有直接交互的功能 eg: 根据XXID找到下属的子结点列表

   3) 与其他服务可能存在关联的情况

5. 从功能分析来设计接口，以restful接口+消息队列的方式提供服务， 中间产出接口文档

6. 详细设计服务内部的数据模型和相互调用关系，使用中不断优化

7. 考虑服务内部对于中间件的选择，redis缓存等的使用

分布式架构应用拆分注意事项：

1.明确拆分原则和拆分需求。

2.梳理出业务模块和之间的依赖关联关系。

3.按照业务为单位，拆分实体、以及应用工程单独部署。

4.按照业务为单位拆分应用服务，避免环形依赖和双向依赖。

5.抽离出公用的接口、实体，以及服务单独部署为公用服务。