《微服务架构的基础框架选择.docxVIP

微服务架构的基础框架选择：Spring Cloud还是Dubbo最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务架构。第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？Round 1：背景Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm 捐赠给 Apache 并加入 Apache 基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。Spring Cloud，从命名我们就可以知道，它是 Spring Source 的产物，Spring 社区的强大背书可以说是 Java 企业界最有影响力的组织了，除了 Spring Source 之外，还有 Pivotal 和 Netfix 是其强大的后盾与技术输出。其中 Netflix 开源的整套微服务架构套件是 Spring Cloud 的核心。小结：如果拿 Dubbo 与 Netflix 套件做对比，前者在国内影响力较大，后者在国外影响力较大，我认为在背景上可以打个平手；但是若要与 Spring Cloud 做对比，由于 Spring Source 的加入，在背书上，Spring Cloud 略胜一筹。不过，英雄不问出处，在背景这一点上，不能作为选择框架的主要因素，当您一筹莫展的时候，可以作为参考依据。Round 2：社区活跃度我们选择一个开源框架，社区的活跃度是我们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会越来越完善，不然当我们碰到问题，就不得不自己解决。而对于团队来说，也就意味着我们不得不自己去维护框架的源码，这对于团队来说也将会是一个很大的负担。下面看看这两个项目在 github 上的更新时间，Dubbo ：/dubbo最后更新时间为：2016年5月6日Spring Cloud ：/spring-cloud最后更新时间为：12分钟前可以看到 Dubbo 的更新已经是几个月前，并且更新频率很低。而 Spring Cloud 的更新是12分钟前，仍处于高速迭代的阶段。小结：在社区活跃度上，Spring Cloud 毋庸置疑的优于 Dubbo，这对于没有大量精力与财力维护这部分开源内容的团队来说，Spring Cloud 会是更优的选择。Round 3：架构完整度或许很多人会说 Spring Cloud 和 Dubbo 的对比有点不公平，Dubbo 只是实现了服务治理，而 Spring Cloud 下面有 17 个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo 只是 Spring Cloud Netflix 中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容。根据 Martin Fowler 对微服务架构的描述中，虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点，但是由于分布式环境下解耦，也带出了不少测试与运维复杂度。根据微服务架构在各方面的要素，看看 Spring Cloud 和 Dubbo 都提供了哪些支持。以上列举了一些核心部件，大致可以理解为什么之前说 Dubbo 只是类似 Netflix 的一个子集了吧。当然这里需要申明一点，Dubbo 对于上表中总结为“无”的组件不代表不能实现，而只是 Dubbo 框架自身不提供，需要另外整合以实现对应的功能，比如：分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。但是 Spring Cloud 中的 Config 组件除了提供配置管理之外，由于其存储可以使用 git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。服务跟踪：可以使用京东开源的 Hydra批量任务：可以使用当当开源的 Elastic-Job……虽然，Dubbo 自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。RPC vs REST另外，由于 Dubbo 是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如 Dubbo 的服务调用是通过 RPC 实现的，但是如果仔细拜读过 Martin Fowler 的 Microservices 一文，其定义的服务间通信是 HTTP协议的 REST API。那么这两种有何区别呢？先来说说，使用 Dubbo 的 RPC 来实现服务间调用的一些痛点：服务提供方与调用方接口依赖方式太强：我们