前言
大家好，一直以来我都本着用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 基础知识 的铺垫。目前正在出一个SpringCloud长期系列教程，从入门到进阶, 篇幅会较多~
适合人群
- 有一定的ava基础
- 想尝试微服务开发
- 有SpringBoot开发基础
- 想学习或了解SpringCloud
- 想提高自己的同学
大佬可以绕过 ~
背景
如果你是一路看过来的，很高兴你能够耐心看完。之前带大家学了Springboot这门框架，熟练掌握了单体应用的开发，如今微服务开发盛行，对我们的技术要求也是越来越高，薪资也是令人兴奋。这个系列将会带大家学习SpringCloud微服务开发，我会带大家一步一步的入门，耐心看完你一定会有收获~
情景回顾
之前带大家学习的SpringBoot，我们部署的时候只需要开一个端口就可以了，我们所有的服务都在这个程序里。大家有想过，当我们的服务不断扩大，如果是上百个功能都在一起，如果某一个功能出现问题了，怎么办？会影响其它功能吗？那肯定会有影响. 如果我把它拆分成单独的服务，独立部署，是不是会好点，就算某一个服务挂了，我其它功能照常用，不至于整个站点都挂掉。但是拆也有问题，这就是本节要讲的内容了，我们一起来认识一下什么是微服务
服务架构的演进
同样的，为了大家更好的理解它，我们依然从它源头说起，本节不涉及代码实操。
单体应用
理解微服务之前，离不开单体应用。在传统后端服务中，我们通常以这种方式架构：
client <--> Server client通常是浏览器,我们把这种方式叫做B/S架构。随着我们应用的丰富，访问的用户也越来越多了，这时候单体服务并不能满足我们的需求了，然后引入了负载均衡, 然后就变成了这样
B/S + 负载均衡
client <--> LoadBalance <--> Server(sv1,sv2,sv3 ...) 我们的服务就会以集群方式部署,用户通过访问负载均衡器访问我们的服务，这样可以解决用户量大的问题。当然我们的服务也有可能是部署到不同的机器
这么做的缺点是啥
虽然一定程度上保证了服务的稳定性，但是对于项目的维护性不是很友好，因为代码都跑在一个服务下, 业务扩张速度是非常快的，我们的代码肯定跟不上业务的步伐，最后会变的非常臃肿，也就是大家经常听到的没时间维护这个，那个，一点都不夸张。对于测试同学来讲，某一个核心功能修复，都要把涉及的流程都测一下，这不得累死，也就是所谓的回归测试周期性长,还没等上线，新的业务又来了....
微服务
说了这么多，怎么去解决这个问题呢？也就我们接下来要讲到的微服务架构
什么是微服务
首先声明的一点，微服务它不是一个框架,也不是Java才有的，它是一种架构方式，就像面向对象，它是一种编程方法.
我一直认为存在即合理，技术也一样，它肯定是存在于某一种场景下能够解决问题的。那么我们微服务能解决哪些痛点问题呢？
我们先看一下微服务需要满足哪些条件:
单一职责(每个服务应该都是独立开发，独立部署，业务独立负责)对外开放(对外提供服务，也就是每个微服务间可以互相访问， 也就是所谓的服务间调用)
如果你的服务之间没有提供对外开放，没有互相调用，其实并不完全称的上是微服务，虽然你的系统也是划分成多个服务
微服务架构
本打算给大家看图的，但是怕大家看不懂，所以还是文字讲解一下
那么我们的微服务是什么样子的呢？
clinet <----> gateway(api网关) <----> Server(Sv1 <-> Sv2, Sv2 <-> Sv3)
首先说一下 gateway这个是api网关，它的作用就是对外(客户端)提供访问比如rest api，为啥要这么一层，因为它好比一个闸口，当请求进来，我们可以统一做鉴权处理，统一记日志，服务调配，服务优先级，统一数据处理等等。没听过，没关系，先了解。Server(Sv1 <-> Sv2, Sv2 <-> Sv3)这个地方是我们的后端服务,可以看到服务间可能是互相调用的
服务间调用
说到服务间调用，这也是一个大问题，为啥这么说❓当我们的服务被拆成若干个小的服务，那我怎么去调用我想要调的服务呢？你可能会说直接调端口不就完了，那如果我的服务是在不同的机器上呢? 你也能会说加个ip+端口不就完了。 那我要是某个服务有多个进程呢？又或是一个集群呢？你怎么调❓ 好家伙，懵逼了吧， 下面就是我要给大家介绍的一个重要的组件,服务的注册与配置
服务配置与注册
其实聪明的同学可能会想，把它做成一个配置中心不就完了，然后服务启动的时候注册一下，当我们要调用服务的时候，去配置中心拿，通过某个特定的值比如key，拿到val，这个值就是我们的服务信息。这时候我们的架构会变成这样:
Server(Sv1 <-> Sv2, Sv2 <-> Sv3) <-----> ConfigServer
当然，这个东西不要我们自己去实现哈~ 因为这种技术已经开源了，我们直接用就好了，都是自动注册与发现，很方便集成,给大家介绍主流的几个eurika(这个已经不维护了)， zooKeeper(dubbo常用,dubbo是alibaba开源rpc框架), consul, nacos(springcloud alibaba), etcd(go写的，go微服务常用它)，后边我们讲SpringCloud主要以Nacos为主
远程调用
之前我们提到过服务间调用，但是还遗漏了一个问题，那就是调用方式是啥, 或许你会讲,跟前端一样以rest为主，这样前端和服务之间都能调,当然，这也是可以的。但是，有没有更好的方式呢？有，那就是rpc调用, 全称Remote Procedure Call Protocol, 翻译过来就是，调用远程就像调用本地一样， 好有点绕口。
先看一下调用本地，是怎么过程。我们调用本地某个方法，只需要代码执行obj.method,这种很方便，那么远程怎么样想本地这样调用呢？因为我们不在一个服务里啊，我调不了你的方法啊❓
怎么解决呢？想象一下，我们约定一个接口不就好了，我只要调用这个接口，就调用了你实现的方法。因为是远程，你得传输数据吧，那怎么传输才能把类传输过去呢？还记得之前学习的序列化和反序列化吗，没错，它在这里就起作用了。dubbo底层也是有序列化过程的, 后边我也会带大家如何整合到SpringCloud
说到rpc其实不止与java， 像grpc它是谷歌开源的高性能rpc框架,它支持多种语言，通过定义proto文件进行约束，go语言用的比较多。
结束语
这里说多了，主要想告诉大家，不要止于Java特定领域的东西，作为开发者，要多去了解其它知识，不是说学了工作用不到，就没啥用了，面试不问，就不学了，这种认知是错误的，很多你对技术的理解都是跟你的认知有直接关联的。就像高考写作文一样，你知道会考啥类型的文章吗，只有平时多积累，遇到了就用上。
再多说一点， 回到学技术，之前知乎上经常会看到这样的问题,Java和go该如何选择，java会被淘汰吗， 说实话，这两门技术我都用，我并不认为谁会被谁取代，反而我觉得只有人会被取代，我觉得问这种问题的人是典型的心虚,给人一种他很慌 的感觉, 正经人谁会问这种无聊问题, 所以大家不要被带节奏。我觉得技术是服务业务的，都是特定场景下有它的优势的，不要比来比去, 老板说用它，你上就完了~
下期预告
本节主要带大家认识了一下什么是微服务以及它架构以及一些场景问题,下期就带大家正式学习SpringCloud，会先给大家讲配置与注册中心Ncos, 下期不见不散 ~
