前言
本来计划周五+周末三天自驾游，谁知人算不如天算，周六恰逢台风来袭，湖州附近的景点全部关停，不得已只能周五玩完之后，于周六踩着台风的边缘逃回上海。周末过得如此艰难，这次就聊点务虚的话题，一是浅谈微服务的架构设计，二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点。
一、微服务的架构设计
之所以想聊一下这个话题，主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手，却不约而同的使用了相同的设计理念，项目结构非常类似。又想到就职于上家公司时接触到的项目的结构设计，于是迸发出了些微的想法。用微服务的架构设计来作为议题，很有喧哗取宠的偏向，所以需要声明一下，本文说的都是基于博主当前浅薄的软件开发经验与贫瘠的架构设计思想得出的浅见，仅是一家之言，而且其中必定包含了很多的确认型偏误，对此现在无法避免。本文的目的只是与大家分享一下自己的想法，仅此而已。
言归正传，当前流传的比较广且提的比较多的设计理念，当属2004年Eric Evans提出的Domain Drive Design，即领域驱动设计，简称DDD。该设计理念可以说与微服务具有相当大的共生依赖关系，也因此，直到最近几年微服务兴起，DDD设计理念才大行其道。该设计理念就是先确定领域，再在此基础上进行设计开发。而领域怎么理解？通俗的理解方式就是一个独立的业务模块，以业务的范围来确定领域的边界。以电商项目为例子，购物车可以看成一个领域，下订单看成一个领域，商城看成一个领域，而当某个领域发展的过于庞大的时候，再对其进行拆分，分成更细分的领域，原则就是保证每一个领域做的是一个单独的事情，做到最大程度的解耦。
以实际项目为例，将一个项目划分成三个一级模块，分别为微服务启动类模块、核心业务模块、通用的中间件等技术模块。而每个一级模块中都有若干个二级模块，每个二级模块就是一个领域，比如业务模块下的二级模块有：商城、购物车、下订单、支付等。技术模块下有：redis模块、swagger模块、数据库模块、消息队列模块等等。业务模块与技术模块中的二级模块，都通过启动类模块进行统一的整合，即确定哪个微服务需要用到哪些模块。这样就可以以最大的灵活性对已有模块进行组合排列。
稍微高深一些的技术人员都知道，没有完美的架构设计，只有更适合当前场景的设计。良好的架构设计不能一劳永逸的解决未来所有的问题，但绝对可以在解决问题时给你提供极大的便捷性。
二、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设计理念，可以对比人类社会中的分工产生效能。每一个工种代表一个领域，不同的领域内部做好自己的功能即可，通过分工能极大提升社会整体的生产力，而通过领域划分，也能提升一个框架、一个组织的工作效能。万事万物皆有联系，古人诚不我欺。