一、个人理解之技术选型：
首先在当前的大环境下，微服务已经是大趋势所在，目前微服务有两个解决方案，dubbo和spring cloud，下面将对比一下两个解决方案的优缺点，然后在说一下为何我最终会选择spring cloud。但是我们不必在这个方便过于纠结，这两个方案在当下都有很多的公司在采用，所以无论学习哪一个都是可以保证能够找到工作的，所以在选择的时候选择自己拿手的喜欢的就可以了，当然如果有心仪的公司那就可以参考一下其技术栈在选择也是可以的，以下之言有部分来自其他博文供参考。
– dubbo：（来自网上）
1、历经阿里双11的考验，大厂背书
2、使用二进制传输，减少宽度的消耗，但同时也增加开发的难度dubbox增加restful
3、有很多阿里出来的员工，在很多公司任职，自带架构所以采用的也比较多
– spring cloud ：
1、东家是大名鼎鼎的spring source产物，社区活跃同时spring组建的有公司专职做开源，所以这个发展会更加稳定，相比于dubbo断更以及不是专职做这个事情，这个更有保证
2、以spring boot为基础构建，sprng boot 整合大量常用的框架技术，使得我们在初学的时候成本大大降低（这里我就想到曾经的同学一个java环境变量配几个周-_-），这个也是很多新兴互联网公司选择的原因，减去大量的配置，使得我们的精力在于开发和学习框架的使用上
3、组件众多，每个组件的替代性强（当然对于选择强迫症的同学这也可能是个缺点，同时的确面临选型的抉择问题），是一套完整的解决方案，不同于dubbo其只提供rpc
综上所述 我是优先于选择spring cloud的，但是这里我依旧说明，dubbo也是可选的，上面由于对于dubbo了解不多，所以讲解也有点片面，所以仅供参考
二、spring cloud 有17各组件，我滴天呀怎么学
是的spring cloud 提供一整套的微服务解决方案，所以体系庞大大致有17个组件。有些同学估计看到这个地方头都大了起来，但是我们要了解我们并不是所有的组件都要去学去用到，学习的二八原则即学20%的东西解决80%的问题，一个模块一个模块的来啃就好了。
其次有很多的时候我们也要有良好的学习方法，记得我曾经阅读mybatis源码的时候，我从配置文件入口开始看，结果一个XMLConfigBuilder里面的的配置解析我看了一个周，最终倒在了ognl上面的解析Mapper文件，后来，我发现这样的学习方法是不对的，我们需要有一个整体的概念，然后采用自顶向下的学习方法，在来逐一攻克从面到线最终才是到点
三、springcloud的整个组件架构图
这个是本人目前理解的一个架构图，在附上一张在网上找的传智播客的一张图（由于以前是看着传智播客王健老师的视频进阶和入门的，虽然现在王老师不在传智，但是他曾经的确是我的领路人，再次是非感谢王健老师，他目前就职于甲骨文华育兴业任CTO一职，负责大数据的教学，公众号 “ [健哥说编程]”）
的确有很多的组件，但是我们现在目前只学习那些关键性的组件即可，后面再慢慢的啃。在笔者的学习的过程中，发现只是单纯的学习如何去用，其实并没有那么难
四、为何要使用微服务
因为网上有大把的介绍，所以把这个内容放在了最后，肯定会有相同的，但是也加上自己的理解在里面。
1、降低模块间的耦合，开发人员更加专注于一个模块的开发，大厂的人一般初期都是拧固定螺丝的，人员的离职对于整个项目影响较小，当然这个maven的多模块也是可以做到的
2、结合docker部署可以做到更加的便捷，针对每个模块来进行升级提升迭代效率，针对单点部署，更容易扩展
3、容错性设计（熔断、限流、服务发现）大大加强对外提供服务的稳定性
4、组件化，提高复用，简化开发
当然缺点也在里面：
– 1、提高了项目的复杂度
– 2、出错不易找出原因
– 3、cap理论的取舍，以及数据库端如何去保证一致性等产生的问题