SpringCloud学习--微服务架构

目录

　　　　微服务架构快速指南

　　　　SOA

　　　　Dubbo

　　　　Spring Cloud

　　　　Dubbo与SpringCloud对比

微服务(Microservice)架构快速指南

　　什么是软件架构?
　　　　软件架构是一个包含各类组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通信层), 它们彼此或和环境存在关系。

　　什么是微服务架构?
　　　　微服务是指开发一个单个 小型的但有业务功能的服务，每一个服务都有本身的处理和轻量通信机制，能够部署在单个或多个服务器上。

　　　　微服务也指一种种松耦合的、有必定的有界上下文的面向服务架构。也就是说，若是每一个服务都要同时修改，那么它们就不是微服务，由于它们紧耦合在一块儿；若是你须要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

　　微服务架构的优缺点？

　　　　优势

• 每一个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务可以被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，不管是在开发阶段或部署阶段都是独立的。
• 微服务能使用不一样的语言开发。
• 微服务容许容易且灵活的方式集成自动部署，经过持续集成工具，如Jenkins, Hudson, bamboo 。
• 一个团队的新成员可以更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队可以更关注本身的工做成果。无需经过合做才能体现价值。
• 微服务容许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其余界面组件混合。
• 微服务可以即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每一个微服务都有本身的存储能力，能够有本身的数据库。也能够有统一数据库。

　　　　缺点

• 微服务架构可能带来过多的操做。
• 须要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 由于分布部署跟踪问题难。
• 当服务数量增长，管理复杂性增长。

SOA（面向服务的架构）

　　SOA是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。面向服务架构，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

 

soa基本架构图

　　1.注册中心： 保存服务提供方暴露的服务信息，常见的注册中心有zookeeper eureka 也可用redis 默认eureka

　　2.服务提供方：提供服务者

　　3.服务消费方：当须要调用远程服务接口时，必须在注册中心发现服务找到服务提供者，从而进行远程方法调

dubbo实现微服务

　　Dubbo是阿里开源的一个SOA服务治理解决方案，文档丰富，在国内的使用度很是高。　　dubbo

• 调用中间层变成了可选组件，消费者能够直接访问服务提供者。

• 服务信息被集中到Registry中，造成了服务治理的中心组件。

• 经过Monitor监控系统，能够直观地展现服务调用的统计信息。

• Consumer能够进行负载均衡、服务降级的选择。

可是对于微服务架构而言，Dubbo也并非十全十美的：

• Registry严重依赖第三方组件（zookeeper或者redis），当这些组件出现问题时，服务调用很快就会中断。

• DUBBO只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖，服务提供者须要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题，就会致使服务调用出错。

• 最为重要的是，DUBBO如今已经中止维护了，对于技术发展的新需求，须要由开发者自行拓展升级。这对于不少想要采用微服务架构的中小软件组织，显然是不太合适的。

新选择SpringCloud

　　与dubbo对比，spring cloud是借助如下组件来实现的：

　　　　　　　　　　　　　　　　　　　　　　

　　上图来自于SpringCloud中文文档 包括了spring cloud如今有的全部组件，以及每一个组件的做用。

　　后续会讲解经常使用组件（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）在这里先不作解释。

SpringCloud与Dubbo对比

微服务须要的功能	Dubbo	SpringCloud
服务注册与发现	Zookeeper	Eureka
服务调用方式	RPC	Restful API
服务路由和过滤	有	Zuul
负载均衡	有	Ribbon
断路器	有	Hystrix
分布式配置	无	Spring Cloud Config
分布式消息	无	Spring Cloud Bus
集群选主	无	Spring Cloud Cluster
批量任务	无	Spring Cloud Task
服务跟踪	无	Sleuth&Zipkin
......	......	......

 

　　很明显，SpringCloud的功能比Dubbo的功能更增强大，涵盖面更广，并且它也可以与Spring Framework、Spring Boot、Spring Data、Spring Batch等其余Spring项目完美融合，这些对于微服务而言是相当重要的。

文档对比

　　Dubbo的  文档 能够说在国内开源框架中算是一流的，很是全，而且讲解的也很是深刻，因为版本已经稳定再也不更新，因此也不太会出现不一致的状况，另外提供了中文与英文两种版本，对于国内开发者来讲，阅读起来更加容易上手，这也是dubbo在国内更火一些的缘由吧。

　　Spring Cloud因为整合了大量组件，文档在体量上天然要比dubbo多不少，文档内容上还算简洁清楚，可是更多的是偏向整合，更深刻的使用方法仍是须要查看其整合组件的详细文档。另外因为Spring Cloud基于Spring Boot，不少例子相较于传统Spring应用要简单不少（由于自动化配置，不少内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应，比较建议了解和学习Spring Boot以后再使用Spring Cloud，否则可能会出现不少只知其一;不知其二的状况。

 

　　虽然Spring Cloud的文档量大，可是若是使用Dubbo去整合其余第三方组件，实际也是要去阅读大量第三方组件文档的，因此在文档量上，我以为区别不大。对于文档质量，因为Spring Cloud的迭代很快，不免会出现不一致的状况，因此在质量上我认为Dubbo更好一些。而对于文档语言上，Dubbo天然对国内开发团队来讲更有优点。

 

　　　　　　　关注博主 后续继续带来Spring Cloud的系列文章，也欢迎各位朋友一块儿交流，共同进步。