　　　　微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自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的系列文章，也欢迎各位朋友一起交流，共同进步。