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

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

一、微服务的架构设计

        之所以想聊一下这个话题，主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手，却不约而同的使用了相同的设计理念，项目结构非常类似。又想到就职于上家公司时接触到的项目的结构设计，于是迸发出了些微的想法。用微服务的架构设计来作为议题，很有喧哗取宠的偏向，所以需要声明一下，本文说的都是基于博主当前浅薄的软件开发经验与贫瘠的架构设计思想得出的浅见，仅是一家之言，而且其中必定包含了很多的确认型偏误，对此现在无法避免。本文的目的只是与大家分享一下自己的想法，仅此而已。

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