微服务的哪些事

微服务的哪些事

微服务拆分没有一个绝对正确的方案，服务拆分的粒度完全要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。既然没有标准答案，要讲解方法和原则的。

拆分方案分为压力、业务

压力模型拆分
业务模型拆分

1 、压力模型拆分
压力模型简单来说就是用户访问量，我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。这么做的原因非常简单，高并发业务相当于前线战场，战况非常激烈，如果我方部署兵力不够（服务器资源），而敌方攻势又过于猛烈（剁手族们疯狂的流量），万一战线失手了服务器压力抵挡不住，我们不希望让这种情况影响到其他用户场景。
举两个例子：

   秒杀： 秒杀是一个典型的低频突发流量的场景，参加秒杀的商品的数量一般不会很多，但是在秒杀开始的时候，尤其是对爆款商品来说（比如新发布的苹果手机），会有一个很明显的突发流量
商品详情页： 商品详情页毫无疑问是电商场景中并发量最大的业务，一笔成功达成的订单背后，可能会调用几十次商品详情页接口（同学们买东西都要货比三家么不是）


我在做具体规划的时候，会尽量把压力模型拆解为三个维度
（1） 高频高并发场景 比如商品详情页，它既是一个高频场景（时时刻刻都会发生），同时也是高并发的场景（QPS - Query per seconds极高）
（2） 低频突发流量场景 比如前面提到的秒杀，它并不是高频场景（偶尔发生），但是它会产生突发流量。再跟大家举一个例子，那就是“商品发布”，对新零售业务来说，当开设一个线下大型卖场以后，需要将所有库存商品一键上架，这里的商品总数是个非常庞大的数字（几十万+），瞬间就可以打出很高的QPS
（3） 低频流量场景 这一类多为后台运营团队的服务接口，比如商品图文编辑，添加新的优惠计算规则，上架新商品。它发生的频率比较低，而且也不会造成很高的并发量。

通常我们建议将高频高并发的场景隔离出来，单独作为一个微服务模块，典型的就是商品详情页的后台服务。对低频突发流量的场景，如果条件允许也可以剥离出来独立组成模块，如果必须和其他业务包在一个微服务下，那一定要做好流控措施（最典型的就是削峰策略），而且还要考虑到异常情况下的补偿机制。对于低频流量场景，我们根据业务模型切分就好了（下面会讲到）。

2、业务模型拆分
业务模型拆分的维度有很多，我们在实际项目中应该综合各个不同维度做考量。我这里主要从主链路、领域模型和用户群体三个维度来讲一下

2.1 主链路拆分
在电商领域“主链路”是一个很重要的业务链条，它是指用户完成下单场景所必须经过的场景。按照我们平时买买买的剁手经验，可以识别出很多核心主链路，比如商品搜索->商品详情页->购物车模块->订单结算->支付业务->财务对账，这是就是一条最简单的主链路。如果这是一场战斗的话，那么主链路就是这场战斗的正面战场，我们必须力保主链路不失守。

电商领域背后还有很多隐藏的核心主链路，比如下单之前的营销优惠结算，它会影响订单的最终价格；再比如用户地址模块，它会影响下单前的配送地址选择。如果这两个模块出了问题，大部分用户恐怕都要放弃下单了。试想，双十一我们添加了一揽子购物车，结果结算的时候发现所有优惠组合都失效了，或者是无法选择配送地址，那也只好放弃了。

各位亲，这里建议将核心主链路拆分，有以下几个目的：

   1、异常容错 为主链路建立层次化的降级策略（多级降级），以及合理的熔断策略Hystrix/Sentinel服务
   2、调配资源 主链路通常来讲都是高频场景，自然需要更多的计算资源，最主要的体现就是集群里分配的虚机数量多。举个例子，就说淘系中台业务中单品营销优惠微服务，在平日非大促阶段（非双11扩容场景）一个服务后台都有接近一万台虚机，一到了发布窗口就要通宵达旦做发布。将主链路服务单独隔离出来，这样有利于根据需要指定资源计划（比如双11阶段为每个主链路服务拟定不同的扩容计划)
   3、服务隔离 主链路是主打输出的C位，把主链路与其他打辅助的业务服务隔离开来，避免边缘服务的异常情况影响到主链路。

2.2 领域模型拆分
领域驱动设计DDD（Domain-Driven Design 领域驱动设计）不是一个新概念，但老外们有个毛病，做什么事情特别喜欢提炼方法论，本来一个非常简单的概念，愣是被吹到神乎其神高深莫测。
其实领域模型是一个很简单的概念，抛掉繁文缛节的方法论，我们一样可以做好领域模型拆分。我举一个例子大家就明白了。阿里集团推出了一套大中台战略，将集团内部的公共领域服务从各个事业部中剥离出来，整合成了一个“集团级别”的大型中台业务。比如说IC订单系统，淘系商品服务，UMP营销优惠服务，汇金平台，用户账号系统等等。
从上面这个例子中我们可以看出，所谓领域模型，其实就是一套各司其职的服务集合。这里涉及到领域和合并和分拆。领域合并的例子就是淘系的营销优惠服务，曾经天猫和淘宝各有一套营销服务，如果不考虑底层技术，从业务层面来说它们做的事情是一样的，都属于营销优惠计算的领域范围，因此后面两条技术线整合成了一套UMP营销优惠服务。领域拆分的例子就太多了，我们做微服务规划的时候要确保各个领域之间有清晰的界限，比如商品服务，和订单服务，尽管他们之间有交集（都围绕商品主数据），但是毕竟是服务于不同领域（商品域和订单域），所以我们要将两者拆分成独立的服务。

3.2 用户群体拆分
根据用户群体做拆分，我们首先要了解自己的系统业务里有哪些用户，比如说电商领域，我们有2C的小卖家，也有2B的大客户，在集团内部有运营、采购、还有客服小二等等。对每个不同的用户群体来说，即便是相同的业务领域，也有该群体其独有的业务场景。
用户群体相当于一个二级域，我们建议先根据主链路和领域模型做一级域的拆分，再结合具体的业务分析，看是否需要在用户领域方向上做更细粒度的拆分。

3.3 前后台业务分离
网约车车主，就会知道网约车业务不仅有一个乘客端app，也有一个司机端app。电商领域也是一样的，我们通过手淘app买买买（前台业务场景），商家通过后台的业务系统管理商品信息（后台业务场景）。在实际项目中通常也会将前台业务和后台业务做一个隔离，这也符合高频业务（前台）和低频业务（后台）的隔离策略。

 

防止过度拆分案例
用户模块服务又细分成用户模块、用户登录服务，给大家讲解下思路
1、现在互联网产品中，用户一旦登录，那么用户可能几个月都不用登录，不存在集中性高并发问题，总之弄一个登录服务属于画蛇添足
2、在某些中小型公司，用户可能就几万，几十万，每日活跃用户也不多，你非得拆一个登录模块，好比一个大饭店没几个客人光顾还多招聘了一些服务员，造成浪费资源，增加成本
3、当公司用户量很大，日活很多，是可以将用户模块中拆分出用户登录模块，就是上面讲的压力模型拆分。

-------------------------------------------------------------------------------------2222--------------------------------------------------------------------------------------------

springcloud和dubbo比较
Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现
SpringCloud是一系列框架的有序集合(一站式解决方案)。它基于SpringBoot的便利性融合了一整套实现微服务的框架并提供了服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等组件，可以说是一个全家桶。
 

两者都是现在主流的微服务框架，但却存在不少差异：

初始定位不同： SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理生态环境不同： SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。调用方式： SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断

两者的生态对比：

Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

--------------------------------------------------------------------------------------333----------------------------------------------------------------------------------------------------

Spring Cloud Ribbon负载均衡策略详解

负载均衡有好几种实现策略，常见的有：

随机 (Random)轮询 (RoundRobin)：轮询策略理解起来比较简单，就是拿到所有的server集合，然后根据id进行遍历      默认方式可用过滤策略 (AvailabilityFilteringRule)：过滤掉连接失败的服务节点，并且过滤掉高并发的服务节点，然后从健康的服务节点中，使用轮询策略选出一个节点返回。响应时间权重策略 (WeightedResponseTimeRule)：根据响应时间，分配一个权重weight，响应时间越长，weight越小，被选中的可能性越低。轮询失败重试策略（RetryRule）：

首先使用轮询策略进行负载均衡，如果轮询失败，则再使用轮询策略进行一次重试，相当于重试下一个节点，看下一个节点是否可用，如果再失败，则直接返回失败。这里还有一个点要注意，重试的时间间隔，默认是500毫秒

并发量最小可用策略（BestAvailableRule）：选择一个并发量最小的server返回

可参考地址：SpringCloud之Ribbon负载均衡策略 - albert飞的博客 - 博客园