浅谈微服务架构与服务治理的Eureka和Dubbo

前言

        原本计划周五+周末三天自驾游，谁知人算不如天算，周六恰逢台风来袭，湖州附近的景点所有关停，不得已只能周五玩完以后，于周六踩着台风的边缘逃回上海。周末过得如此艰难，此次就聊点务虚的话题，一是浅谈微服务的架构设计，二是聊聊微服务中普遍用于服务治理的Eureka与RPC框架Dubbo异同点。

1、微服务的架构设计

        之因此想聊一下这个话题，主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两我的之手，却不约而同的使用了相同的设计理念，项目结构很是相似。又想到就任于上家公司时接触到的项目的结构设计，因而迸发出了些微的想法。用微服务的架构设计来做为议题，颇有喧哗取宠的偏向，因此须要声明一下，本文说的都是基于博主当前浅薄的软件开发经验与贫瘠的架构设计思想得出的浅见，仅是一家之言，并且其中一定包含了不少的确认型偏误，对此如今没法避免。本文的目的只是与你们分享一下本身的想法，仅此而已。

        言归正传，当前流传的比较广且提的比较多的设计理念，当属2004年Eric Evans提出的Domain Drive Design，即领域驱动设计，简称DDD。该设计理念能够说与微服务具备至关大的共生依赖关系，也所以，直到最近几年微服务兴起，DDD设计理念才大行其道。该设计理念就是先肯定领域，再在此基础上进行设计开发。而领域怎么理解？通俗的理解方式就是一个独立的业务模块，以业务的范围来肯定领域的边界。以电商项目为例子，购物车能够当作一个领域，下订单当作一个领域，商城当作一个领域，而当某个领域发展的过于庞大的时候，再对其进行拆分，分红更细分的领域，原则就是保证每个领域作的是一个单独的事情，作到最大程度的解耦。

        以实际项目为例，将一个项目划分红三个一级模块，分别为微服务启动类模块、核心业务模块、通用的中间件等技术模块。而每一个一级模块中都有若干个二级模块，每一个二级模块就是一个领域，好比业务模块下的二级模块有：商城、购物车、下订单、支付等。技术模块下有：redis模块、swagger模块、数据库模块、消息队列模块等等。业务模块与技术模块中的二级模块，都经过启动类模块进行统一的整合，即肯定哪一个微服务须要用到哪些模块。这样就能够以最大的灵活性对已有模块进行组合排列。

        稍微高深一些的技术人员都知道，没有完美的架构设计，只有更适合当前场景的设计。良好的架构设计不能一劳永逸的解决将来全部的问题，但绝对能够在解决问题时给你提供极大的便捷性。

2、Eureka与Dubbo

        如今网上，更多的是用Dubbo与Spring Cloud进行比较，从微服务的模块功能上比较两者的异同。但这样比较未免有点偏，Dubbo的定位更多的是作服务治理，而不是提供一揽子的微服务架构解决办法，因此比较的结果就是Spring Cloud这个功能有那个功能有，但Dubbo这个没有那个没有。今天我们从服务治理的角度，用Spring Cloud经常使用的Eureka与Dubbo进行比较，看看两者的异同。

        要说这二者，不得不提一下分布式架构中的CAP理论，即一个分布式框架，只能同时知足C一致性、A可用性、P网络分区容错性这三者中的两个，不可能同时兼备三者。

        从这个角度上来看，Dubbo推荐的注册中心首选ZK，而ZK是一个知足CP的框架；Eureka因为其架构设计，更多专一于AP。

        对于容错机制，Dubbo自身实现了多个错误处理方式，好比失败切换Failover、快速失败Failfast、失败安全Failsafe等，Eureka是借助于Spring Cloud中的熔断器Hytrix实现的容错。

        对于负载均衡，Dubbo自身实现了多种负载均衡方式，好比随机权重、哈希一致性等，Eureka一样是将此功能外放，经过Ribbon等实现了负载均衡。

        服务注册及发现，Dubbo自身封装了NettyClient等通信工具，而Eureka都是采用的应用层通信HttpClient。

        由此能够看出，微服务框架自己也是采用了领域拆分的设计理念，将相对独立的不一样功能拆分红单独的模块，想用什么模块就组合什么模块。从这个角度上看，Dubbo更多的是提供了一个组合起来不可拆分的总体功能，而Eureka与其余组件则简单轻便的多。

后记

        其实能够再延伸一步，感受微服务的这种DDD设计理念，能够对比人类社会中的分工产生效能。每个工种表明一个领域，不一样的领域内部作好本身的功能便可，经过分工能极大提高社会总体的生产力，而经过领域划分，也能提高一个框架、一个组织的工做效能。万事万物皆有联系，古人诚不我欺。