前言
接触Java即将一年，工作半年多了。经历过Dubbo的项目，现在做的是SpringCloud的项目。在微服务成为最潮流技术的时代，下文将从微服务的概念开始，谈谈自己对两个微服务主流框架的理解。
什么是微服务
先看看业界的大牛是怎么定义微服务的
马丁福勒的论文 https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
我的理解是，微服务的核心是将传统的一站式应用，根据业务、技术或者领域模型拆分成一个个服务，彻底的做到去耦合。每个微服务都是独立的进程， 每一个微服务都提供单个业务功能的服务，从技术角度来说，就是小而独立的处理过程。所以要先充分的了解业务，才能搭建出最合适的微服务架构。
技术的选型
并不是任何场景都适合微服务的。无脑的追寻使用新技术，而不选择最适合业务场景的架构体系，会起到事倍功半的效果。先来看看微服务结构解决了哪些问题，就能清楚什么情况下适合使用微服务架构了。
在分布式开发之前，单体式开发是主流。所有的业务模块，所有的业务逻辑都在一个服务中，这样会有哪些问题呢？
1.在日常开发中，容易照成代码提交的冲突。
2.两组开发都在开发或者修复BUG，容易照成相互等待的局面。
3.假设某个业务模块挂了，那就会导致整个系统的服务都不可用，这在生产上是十分可怕的。
4.数据库的压力很大，所有的请求都访问统一数据库，就算做了redis缓存，在高并发的情况下，还是很容易直接击穿MySQL数据库的。
5.集群部署容易照成浪费资源的情况，比如下单功能的访问量远远大于登入功能，但在单体式系统中无法拆分出来，在服务器扩展时，为了满足订单的需求，无法做到单个业务模块的水平扩展。
6.在单体式高耦合的情况下，修改某一业务逻辑，可能会导致其他的功能出现问题。
…
总结起来就是，微服务可以解决单体式系统中，吞吐量低、水平扩展性差、开发效率低等问题。所以在实际场景中，比如电商系统，能明确的分为订单、运输、仓储、结算等模块，并且在特定时间段，并发量是较高的，就可以使用微服务架构，在分布式集群部署的时候，对于订单这样访问量大的业务模块，就可以多部署几台服务器，实现资源的合理使用。但像公司内部的OA系统，就没必要使用微服务架构了，一是因为并发量小，二是因为功能基本稳定，后续的变动不会很大，使用单体式系统可以起到降低开发成本的目的。
Dubbo
Dubbo是阿里的一套RPC框架，可以看作是SpringCloud的子集。各个微服务之间通过Netty请求实现远程调用。上手容易，还是熟悉的控制层调用业务层的方式，面向接口编程。注册中心官方推荐的是 Zookeeper，在第一个项目中，由于公司有服务管理台类似于腾讯云的TFS，有可视化的管理页面，可以清楚的看到哪些服务注册上去了，哪些服务没有，还可以手动去禁用和开启服务，所以用起来还是很舒服的，出现服务调不通的问题，看一眼管理台就能马上发现问题。 但Dubbo也仅仅是一个RPC框架，对于网关、分布式配置中心、断路器等，只能自己去集成第三方技术，所以Dubbo就像是
组装机，除了核心主板(RPC框架)其他全凭个人喜好，容易出现兼容性问题。
SpringCloud
接下来说说SpringCloud。推荐一下B站上面，尚硅谷的SpringCloud的学习视频，只要坚持学习，上手起来相当快，自己搭个Demo基本上就能掌握SpringCloud的常用技术栈了。SpringCloud就像是品牌机，他是一整套的微服务解决方法，从路由到服务注册与发现，再到服务的熔断与治理，包括消息总线和数据流，听起来感觉好像很复杂，但任何SpringCloud的技术栈，用起来就是两步。第一步，在pom文件中引入相应技术的GAV坐标。第二步，在启动类中开启相对应的@EnableXXX注解。就是这么简单，任何接触过Web开发的，肯定都能快速的上手。为什么说Spring全家桶会统一中小型企业的后端开发呢？原因很简单，成本低，上手快。Spring中文社区的热度那么高，遇到问题谷歌一下，社区逛一逛，基本就能解决。而Dubbo毕竟停滞几年了，虽然重启了，但团队也已经换人了，社区的热度不高，遇到问题的时候，解决起来难度大，还需要去考虑框架与集成的技术兼容性问题。我敢说，在使用Spring的时候，遇到的90%问题，都是已经有人遇到过的，剩下的10%，一半是十分细小的问题，还有一半的问题只需要放一放，沉淀沉淀，睡一觉起来就能解决。就像不要重复造轮子一样，也不要去踩前人帮你踩过的坑。
总结
虽然说Dubbo的RPC调用相比于SpringCloud的Http调用性能更高。但能用硬件(钱) 解决的问题，已经不是大问题。并且在流量大爆炸的时候，高并发是任何一个系统在设计的时候在需要去考虑解决的问题。Dubbo选用的Zookeeper在这里就输给了SpringCloud一大截了。Zookeeper保证的是CP，节点的选举导致的30-120S的不可用，在双11的时候能接受吗？而Eureka保证的是AP，每个节点都是平等，就算遇到了网络故障，自我保证机制也不会导致服务的不可用而造成数据的丢失。
上图是Spring官网中的SpringCloud的架构图。系统架构搭建需要用的技术，Spring全家桶里面都有。各项技术都可以完美和SpringBoot整合来用。不过呢，Hystrix和HyStrixDashborad整合起来用的时候，只能兼容SpringBoot1开头的版本，如果使用2开头的版本，需要自己去重新定义ServletRegistrationBean这个Bean，修改他的URL映射路径。最后说一下我在搭建SpringCloud的时候踩过的坑。
1 - Eureka是CS结构，客户端和服务端对应的GAV坐标是不一样的，启动类上对应的注解也是不一样的。在Eureka服务端的配置文件中，一定要把这段加上
防止Eureka服务端把自己本身也注册到Eureka上，否则启动就会报错了。然后Eureka的集群部署，多个地址是用逗号分开，不是空格。
2 - Ribbon自定义负载均衡算法不能放在@ComponentScan扫描的当前包以及子包下，否则自定义的这个配置会被所有的Ribbon客户端共享，达不到特殊化定制的目的。重点来了，
启动类上@SpringBootApplication是包含@CompoentScan的，所以说，自定义的负载均衡算法不能放在启动类的包中。
3 - Zuul记得加上如下配置
不加的话，通过Zuul既可以通过Eureka上微服务的名字去访问对应的微服务，又可以通过这里设置的path去访问，一个微服务有两个入口，是不规范的。