这篇文章主要是想介绍我们团队在业务发展中业务服务的架构模式变迁，以及服务之前通信的方式变化。
服务化实现
点评在2012年左右就推荐一些共用系统服务化，到2015年公司全面推进服务化建设，业务逻辑几乎全部沉淀到后台服务，前台的web只提供简单的http 接口，而APP则只负责展示功能。
因此，在我们开始开发时就采用全部服务化的方法。点评自己开发了一套RPC框架——pigeon，这个在之前的博客RPC是什么 有过详细的介绍。
在这里主要介绍后台服务化的变迁模式。
业务背景
点评的KTV在线预订启动一年多了，一年的过程业务从小到大，再到双平台融合，业务稳定发展；这一年经历是一个大公司内部的创业构成，业务类型不断扩展，要求业务系统能够快速支持业务。
KTV在线预订是一个O2O中到店消费类，业务系统需要提供到店前决策，购买和到店消费及后期的商家结算。
业务初期（MVP阶段）
在业务初期，业务模型基本都是不清晰的，在产品提出基本的产品模型之后，需要在线上快速验证产品。
这个阶段因为要快速上线，因此我们只开发一个订单服务，这个订单服务集合了订单功能和预订功能，以及退款等功能，几乎集成了MVP阶段流程的功能。这时候各个阶段功能的数据也都是绑定在订单上的。如预订阶段的数据，退款阶段的数据等。
扩展业务
这个阶段的业务快速扩张，需要支持多种扩展的业务类型，比如预订的模式就会划分出库存模式和商家接单的模式。
- 库存模式：是商家预先设定好当日的库存量，只要用户购买是有库存就会立即购买成功。
- 商家接单模式：商家并没有给出确定，需要用户确定预订之后，商家才会接到通知，然后由商家决定是否接受预订，如果不接受则预订失败。
这个阶段业务开始处于快速发展中了，有了前期一定的用户和订单积累，因此这个阶段需要快速开发同时也要支持更多的业务类型。
这个阶段因为有着业务快速发展的要求，难以做到数据的独立，因此只能在服务层面做出隔离，但是因为服务都共用了一套订单数据模型，因此其他服务对订单的读取和修改也都是通过订单服务来完成的。这种模式下初步解决了业务扩展的问题，如多做预订模式，多种退款场景等；但这种方式的缺点非常明显：
- 数据混合，导致数据模型混乱，且难以在根源上支持业务扩展；
- 订单服务成为单点服务。
稳定发展期
业务开始进入稳定发展期，对系统的稳定性和可靠性有了更高的要求，而且这个阶段的流量也开始变高；同时也需要有新的业务类型引入。为了解决上面所提到的问题就需要通过分离数据来解决上面数据混合的问题。
这种模式情况下，相互之前的业务数据独立了，单点的服务也基本处理了，这种架构以及可以基本支持目前的业务。
但是很多服务对订单的访问基本都是查询订单数据，而这部分请求也最高的，但却并不是最重要的；对于订单业务而言，最重要的核心节点是下单和订单状态流转。因此我们在使用了上面的模式之后，渐渐将订单服务裂变出创建订单服务和订单查询服务。
未来服务的规划
目前这个阶段，有很多的逻辑需要查询订单的信息，而订单信息针对调用方来说需要订单角度的很多信息，如订单退款信息（退款时间，是否退款成功），消费状态等等；这些信息需要调用多个服务（如订单查询服务，消费服务和退款服务），而这种信息的查询需要有多个业务方来调用，如果这个功能都需要业务方查询组装的话，反而使得业务过于零散。因此在未来将会新增一些聚合服务，而原有的服务将成为基础服务；聚合服务主要是调用基础服务，并将基础服务的数据进行组装和流程处理；基础服务则定义更为基础，只处理本领域内的业务。
服务的设计模式
通过上面的模式变迁，在这个过程中，主要使用到了一下的集中服务设计模式：
- 共享数据模式
- 异步消息传递模式
- 聚合期的服务模式
这些概念在之前的一篇博客我们需要什么样的微服务 中有更为详细的介绍。
References
RPC是什么
我们需要什么样的微服务
打赏支持我写出更多好文章，谢谢！
打赏作者
打赏支持我写出更多好文章，谢谢！
任选一种支付方式
