4.2　微服务的拆分规范

4.2.1　领域模型

领域模型是领域驱动设计（Domain-Driven Design，DDD）中的概念，它是对具有清晰边界的领域对象的一种抽象表示（这种抽象是从业务结合技术的视角出发），领域模型强调的是“边界划分”，它通常只关注业务复杂度，从业务视角将应用划分为一个个独立的业务子域，比如订单域、商品域、导购域等；再根据不同的需求场景及团队对领域知识的不断积累和认知，对领域内的业务做进一步划分。

4.2.2　计算密集型业务和I/O密集型业务

计算密集型业务通常分为CPU密集型和GPU密集型两种，它们的特点都是需要大量的计算资源来完成自身业务，对网络带宽的占用不多。比较典型的业务是淘系业务的营销优惠计算引擎和用户画像系统，以及各大互联网公司中的机器学习系统。将核心主链路的计算密集型业务拆分成独立的微服务，可以有针对性地调配高算力类型的硬件资源进行扩缩容。

I/O密集型业务的特点是需要占用大量网络带宽、存储介质和内存空间以完成自身业务，但只需少量的计算资源。这类业务的典型代表是文件的上传下载功能，比如淘系商品的图片空间和视频空间服务，抖音的小视频上传等。将这类业务拆分为独立服务，可以有针对性地调配存储资源。在网络搭建上，我们推荐使用专线服务该类业务，以避免发生网络阻塞从而影响主链路系统。

4.2.3　区分高频、低频业务场景和突发流量

分析业务的使用频率是服务拆分的一个重点。以电商场景为例，主链路业务中典型的高频场景是商品主搜、商品详情页等导流端场景，而后台商品发布服务则是低频场景。区分高频、低频场景，不仅可以对集群资源进行更加精准的调配，在大促等峰值流量冲击阶段，也可以做到细粒度流量整形和服务降级（牺牲非主链路上的低频场景能力，将服务器资源调配给主链路上的高频场景）。

针对双11爆款商品、微博热搜等典型的突发流量场景，我们也有特殊的服务拆分手段。在某个资源成为突发热点的前后，其业务属性并没有发生本质的变化，为了防止热点资源影响整个业务，在服务拆分手段上我们倾向于使用“热点隔离”的方案。对于秒杀活动等可以预知的突发热点，我们可以预先将底层数据、缓存从主库迁移到独立的“热点库”，甚至可以将服务请求路由到专门搭建的热点集群。而对热搜等无法提前预知的热点来说，则可以通过流技术（比如，使用Stream分析RPC接口日志的方式来统计访问量）分析统计实时业务数据，在某个资源接近热点阈值的时候，将其动态迁移到热点库，这也是目前一线大厂对热点数据的主要拆分手段。

4.2.4　规划业务主链路

主链路规划是大型应用微服务治理中必不可少的一个环节，其目的是识别出最低限度地完成业务所必须调用的服务链路。以电商场景为例，商品搜索、详情页、添加购物车和订单结算是完成下单必不可少的主链路服务，而商品用户评论、导购推荐栏等功能并不包含在主链路内，在大促等大流量场景下可以通过弹性缩容和降级的方式，把边缘业务的系统资源让给主链路上的关键服务。

主链路服务的故障将对业务产生重大的影响，通过对主链路服务进行细粒度的服务拆分，就可以根据具体的业务场景，更加细粒度地运用限流策略、弹性计算和降级策略等流控和容灾技术，在峰值场景下保障主链路服务的可用性。