4.2.1.springcloud_ribbon使用及原理【上】
时长：1h
1.1.spring cloud生态
>Spring Cloud Netflix OSS套件：
ribbon,hystrix,feign,Eureka
>Spring Cloud Alibaba
dubbo,nacos,seata,rocketMQ/sentinal
1.2.Spring Cloud Netflix Ribbon
ribbon就是一个工具组件。
1.2.1.微服务架构下的通信需求
对于开发工作，首先面临业务需求的分析，业务需求可能来自老板，也可能来自运营，运营得到需求，给到产品.
如果有产品，产品负责人会对业务进行整理、拆解，然后做成prd文档，然后prd评审，然后由开发给出技术方案，
方案设计好之后，开始开发，然后通过测试，最后上线。
技术的发展，是基于业务需求来驱动的。不管是技术组件，还是业务组件，都会涉及到需求。对于ribbon这个组件来说，
它的需求是什么呢？
首先是通信。为什么有这样的结论，从下面的业务拆分来说明。
最初，系统大多设计成单体架构，如下所示：
逐渐演变到分布式架构，如下所示：
分布式架构，意味着业务拆分布署，也就涉及服务拆分，服务之间的通信是跨系统，
跨服务器进行的，即所谓的远程通信。服务器间传输数据，是通过网络进行通信的。
1.2.1.1.远程通信如何实现？
涉及到远程通信，就需要相应的解决方案，为了解决这类问题，不同组织来开发出自己的组件，
并慢慢开源。
远程通信，首先是使用什么样的通信协议，http或rpc.在微服务领域，rpc协议应用十分广泛。
基于rpc协议，产生开源组件，如：dubbo,...
基于http协议，出现restful风格api
1.2.1.2.RESTful Http协议通信
RESTful是一种基于http协议的风格性规范。应该着重关注restful的约束条件和原则。
它有良好的可读性，扩展性。无状态性，便于横向扩展。
>http方法，来约束资源操作类型【服务器上的图片，文本都是资源】，操作类型【对应请求类型post,get,put,delete】
>rest是面向资源的，如：根据订单id查询订单，请求url为/order/{id}
1.2.2.服务拆分
1.2.2.1.服务拆分的背景
为什么要做服务拆分？主要是由于业务的发展，技术成熟。
》系统已经运行很长时间，无法满足业务需求
》一开始就采用微服务架构，做好预先规划
1.2.2.2.微服务怎么拆分？
在做项目时，很多人对于边界划分，很不清晰。有一些功能，好像放在用户，订单，商品模块
都是可行的，对于这个业务模型，如何正确地归置在恰当的业务领域里面？
拆分的依据，通常有：
》业务层面
》功能层面
所以，这个归置，有时确实是难以区分的，这就能体现开发人员的开发经验了。
还有，拆分的意义是什么？拆分的前提是什么？应该做哪些准备？
1.2.2.3.拆分的前提
考虑收益：为了支撑更大的用户量，用户用得越多，卖得越好，收益就越好。
收益体现在什么地方呢？
》问题驱动---用户群增加，满足某种个性化需求，从而修改。
》前置化的规划
渡过这个问题休整这一混乱期，待系统趋于稳定，然后考虑系统优化。做全面的重构，待到下一次
的活动开展时，系统能够很好支撑，做一个前置化的规划。
并根据用户数据，大致估测出接下来系统的流量有多少，系统能不能支撑这么大的体量，需要多少服务
器节点，系统监控怎么做到？运维怎么做？
》性能提升。
》团队(运维)。当系统变得庞大之后，带来问题是开发团队能否跟上？
1.2.2.4.拆分的准备
1.2.3.RestTemplate