Dubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过 Spring 配置的方式即可完成服务化，对于应用无入侵，设计的目的还是服务于自身的业务为主。 微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。 各大互联网公司也有自研的微服务框架，但其模式都与这二者相差不大。 微服务主要的优势 降低复杂度 将原来耦合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。 每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界；每个服务开发者只专注服务本身，通过使用缓存、DAL 等各种技术手段来提升系统的性能，而对于消费方来说完全透明。 可独立部署 由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。 容错 在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。比如通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。 扩展 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。 当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。 本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较 Dubbo 和 Spring Cloud 这 2 种开发框架。 架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。 核心部件 微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对 Dubbo 和 Spring Cloud 做出对比。 总体架构 Dubbo 核心部件（如下图）: Provider：暴露服务的提供方，可以通过 jar 或者容器的方式启动服务。 Consumer：调用远程服务的服务消费方。 Registry：服务注册中心和发现中心。 Monitor：统计服务和调用次数，调用时间监控中心。（Dubbo 的控制台页面中可以显示，目前只有一个简单版本。） Container：服务运行的容器。 Dubbo 总体架构 Spring Cloud总体架构（如下图）： Service Provider： 暴露服务的提供方。 Service Consumer：调用远程服务的服务消费方。 EureKa Server： 服务注册中心和服务发现中心。 Spring Cloud 总体架构 点评：从整体架构上来看，二者模式接近，都需要服务提供方，注册中心，服务消费方。 微服务架构核心要素 Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。 Dubbo 提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善。例如： 分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。 服务跟踪：可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。 批量任务：可以使用当当开源的 Elastic-Job、tbschedule。 点评：从核心要素来看，Spring […]
View Details