微服务设计和拆分的原则

1.微服务的接口粒度应该多大？
完成一个用例的作为服务服务接口的粒度是合理的，拆的太细面临事务问题。
2.微服务到底应该如何拆分和设计？
业务模型拆分：前后台业务拆分、主链路查费、领域模型拆分、用户群体拆分
压力模型拆分：对于高并发量的业务，尽可能独立成微服务拆分

1.压力模型拆分
压力模型拆分，就是说根据用户对业务的访问量的高频进行拆分，假如存在某些服务的调用量特别巨大，我们可以将此服务独立出来单独部署。
对于压力模型我们还可以细分三个维度
1.高频高并发的情况。
例如：商品详情页查询。他是一个高频高并发场景。
2.低频突发流量情况。
例如：秒杀。他是一个低频高并发场景。
3.低频低流量情况。
例如：商品的维护、上下架等操作。
对于高频高并发、低频突发流量这两种情况，可以独立组成模块。而低频低流量情况这个根据业务属性进行拆分，后边心签到会在说明。

2.前后台业务分离拆分
我们在网约车业务中会有一个乘客端、司机端、管理员端。同样在商城系统里，我们也会有
买家手机端（前台业务场景）、商家后台（后台业务场景）。在实际的开发过程中我们会将前台
后台独立拆分开来做一个隔离，这其实也符合高频场景（手机端）、低频场景（后台）的拆分原则的。

3.根据用户群体进行拆分
根据用户群体进行拆分，第一我们首先要需要知道我们系的目标用户有谁，例如ERP系统，有公司员工、有财务人员、HR等参与者。
对于不同的用户，他们都有自己特有的业务场景，用户的参与者具有分明特性的业务特别适合作为一个模块。我觉得首先会需要根据领域模型、主链路流程进行拆解，
然后在根据用户的领域方向和使用场景在进行细粒度拆分，根据用户群体进行拆分可以作为，领域模型、主链路流程拆解的一个补充。
具体领域模型拆解、主链路流程拆解后边在细化。

4-根据主流程拆分
在商城系统里有一个重要的主流程，那就是用户商品搜索-》商品详情-》购物车-》订单模块-》支付模块。
主流程是我们这个商城系统的核心业务，使我们需要固守的一个流程。
当然在这后边我们还隐藏这很多核心流程，比如:优化结算、收货地址、物流模块等，这当中里面的任意模块
奔溃、错误都可能导致用户放弃购买。
所以我们可以根据核心主流程模块进行拆分，主要能够带来以下几个好处：
1.服务隔离：当用户下单完成时，需要通过淘宝手机客户端推送一个消息给用户，消息推送服务的问题，不应该
到用户下单的操作。我们可以通过领域事件的走异步的策略解决这个问题。避免边缘的服务异常，影响到主流程。
2.异常容错：主流中的模块需要合理的设计降级策略、熔断策略。防止因为部分程序问题导致服务器雪崩的情况。
3.资源调配：针对主流程中的模块，在需要的时候我们可以分配更多的服务器资源。独立分拆主链路模块独立部署。

5.根据领域模型拆分
领域模型拆分，首先我们需要理解什么是领域。领域即问题域、问题空间、领域是一个边界范围。一个东西在售卖的时候他叫商品，当进行运输的时候叫做货物，他们处在不同的问题域里，所有我们在划分领域的时候，通用语言的作用域就可以做为微服务拆分的依据的。

6. 基于技术异构等因素

领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就是说领域模型内部不同的功能存在技术异构的问题。由于业务场景或者技术条件的限制，有的可能用.NET，有的则是 Java，有的甚至大数据架构。对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。

7.基于组织架构和团队规模

我们一个团队可能就10个人，当我们面对一个小商城系统时，我们可能会噼里啪啦一下拆了20多个微服务出来，这个是很恐怖的。因为一旦微服务化很多问题都会接踵而来，事务、超时、熔断、限流、服务监控、排错等问题。我们有限人员可能一下都耗费在这与业务无关的上面去了，这个是很严重的问题，过渡服务化。我觉得根据人员配置情况进行模块划分会是一个很合理的方案。首先我们粗粒度的形式进行划分。各领域之间还是遵循DDD的设计方法论，该怎么拆分模块就怎么拆，虽然他们可能都在一个大的模块里，但是这个不影响。当那天我们项目成功了，用户上来了，我们再把这些模块拆分出去也是简单的。因为我们已经划分好限界上下文，划分好领域，代码之间也不存在耦合和强引用关系。
不知道大家有没发现这里面其实还隐藏了一个问题就是人员的问题。服务边界我们虽然划分好了，人员那到底应该怎么去配比呢？
例如：我们按照业务来划分，根据粒度大小，一般会存在以下两个情况。
1.分为商品、交易、用户3个服务；
2.分为商品、订单、支付、物流、买家、卖家6个服务。
但是我们只有10个人的情况下，我们该如何选择以上两种方案。
我们可以依据“三个火枪手”原则。三个人分配一个服务的原则进行人员配比。具体什么是"三个火枪手原则"看下图

除非有意识地优化组织架构，否则微服务的拆分应尽量避免带来团队和组织架构的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。我们可以仿照管理学关于一个一层管理团队的理想大小，其答案不一定，但一般是不要超过10个，我个人比较舒服的数目是3到7个,拆分后的微服务项目团队规模保持在5+-2 人左右为宜。

8.基于安全边界

于安全边界有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响。

9. 基于业务需求变化频率

识别领域模型中的业务需求变动频繁的功能，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。这是因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响。