SpringCloud学习总结

一、SpringCloud

　　就目前而言，对于微服务，业界并没有一个统一的，标准的定义。

官方解释：

　　通常而言，微服务架构师一种架构模式，或者说是一种架构风格，他提倡将单一的应用程序划分成以小组的服务，每个服务运行在

其独立的自己的进程内，服务之间相互协调，相互配置，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通，每个服

务都围绕这具体的业务进行构建，并且能够独立的步数到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体

的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，

可以使用不同语言来编写服务，也可以使用不同的数据存储。

自我理解：

　　以前的一站式应用，如果有一个业务宕机，那么整个项目都得宕机。微服务的核心就是将根据业务拆分成一个一个的服务，彻底的解耦，

每个服务之间互不干扰，它们都是可以独立运行的，其中有一个宕机其余的还可以正常运行，每个微服务之间提供单个业务功能

，一个服务一件事情，从技术角度看就是一种小而独立的处理过程，累死京城的概念，能够自行单独启动或者销毁，拥有自己独

立的数据库，而且可以使用不同的语言来开发。

 

 

二、微服务与微服务架构

微服务

　   微服务强调的是服务的大小，它关住的是某一个点，是具体解决某一个问题的服务应用，可以看做一个一个的Model

微服务架构

　　微服务架构是一种架构模式，它提倡将单--应用程序划分成-组小的服务，服务之间互相协调，互相配合，为用户

提供最终价值.每个服务运行在其独立的进程中，服务于服务间采用轻最级的通信机制互相协作，每个服务都围绕

若具体的业务进行构建，并且能够被独立的部署到生产环境中，另外，应尽量避免统--的，集中式的服务管理机

制，对具体的一一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建.

三、微服务的优缺点

　　优点：

　　1.单一职责（每一个服务只干一件事情）。

　　2.开发简单，开发效率高。

　　3.微服务是松耦合的，是有功能意义的服务，无论是开发还是部署都是独立的。

　　4.微服务可以使用不同的语言开发。

　　5.每个服务足够内聚，足够小。

　　缺点：

　　1.数据不一致

　　2.服务间通信成本

　　3.分布式的复杂性

四、微服务的技术栈

服务开发	SpringBoot, Spring ,SpringMVC
服务配置与管理	Netflix公司的Archaius，阿里的Diamond
服务注册与发现	Eureka，Consul，Zookeeper
服务调用	Rest，RPC，gRPC
服务熔断	Hysitrix，Envoy
负载均衡	Ribbon，Nginx
服务接口调用（客户端调用服务的简化工具）	Feign 等
消息队列	Kafka，RabitMQ，ActiveMQ
服务配置中心管理	SpringCloudConfig，Chef
服务路由（API网关）	Zull
服务监控	Zabbix，Nagios，Metrics，Specatator
全链路追踪	Zipkin，Brave，Dapper
服务部署	Docher，OpenStack，Kubernetes
数据流操作开发包	SpringCloud Stream（封装与Redis，Rabbit，Kafka等发送接收消息）
事件消息总线	SpringCloud Bus

 

 

 

 

 

 

 

 

 

 

五、为什么选择SpringCloud作为微服务架构

　　1.选型依据

　　整体解决方案和框架成熟度

　　社区热度

　　可维护性

　　学习曲线

　　2.当前各大公司用的微服务有哪些

　　阿里：dubbo+HFS

　　京东：JSF

　　新浪：Motan

　　当当网：DubboX

六、SpringBoot和SpringCloud的关系

　　SpringBoot专注于快速方便的开发单个个体的微服务。-jar

　　SpringCloud是关注全局的微服务协调整理框架，他将SpringBoot开发的一个一个单体的微服务整合并管理起来，为各个微服务之间提供；配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。

　　SpringBoot可以离开SoringCloud独立使用，开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系

　　SpringBoot专注于快速，方便的开发单个个体微服务，SpringCloud关住全局的服务治理框架

 七、Dubbo和SpringCloud的对比图

　　

八、spring Cloud与dubbo技术选型

1.架构完整度:

　　与spring cloud相比，dubbo的架构完整度不够，其本身只提供了服务注册中心与服务治理两个模块，而spring cloud到现在为止，已经提供了服务注册中心，服务治理等各个模块，并且还在增加中。虽然dubbo也可以整合第三方框架，但是搭建出来的dubbo架构可能出现兼容性问题，而spring cloud不会，因为其每一个模块都是经过严格测试的，几乎不存在兼容性问题。如果将spring cloud比作品牌机，那dubbo就是组装机

2.社区活跃度:

　　与spring cloud相比，dubbo社区活跃度相对较低，社区活跃度的高低将影响项目维护成本，在社区活跃度很高时，一般项目中遇到的问题都可以在社区中找到响应的解决方案

3.通讯协议:

　　dubbo服务间通讯采用rpc，而spring cloud采用的时http的rest。rpc对于业务接口有很强的依赖性，生产者和消费者都需要依赖相同的接口，并且还需要通过严格的业务接口版本来进行管理，这种依赖在大型微服务项目将会成为一个很大的问题，相比rpc，rest更加轻量化，服务调用者和提供者间的依赖仅仅是一纸契约，一段文本，不存在代码层面的强依赖，服务提供者和调用者之间还可以通过不同的语言来实现，只需要提供rest接口就可以通讯。

4.技术改造和微服务开发：

　　国内的开发团队选择dubbo的一个很重要的原因就是官方文档，dubbo提供了高质量的官方文档，而spring cloud都是英文版的，并且文档内容要比dubbo多的多，文档内容更偏向模块整合，要对每个模块的进行更深入的了解，需要查看更为详细的文档，对于中小型团队来说,阅读英文文档的成本必须要考虑的