通过请求体验单体到微服务的演变过程

1.前言

接触spring cloud已经有很长一段时间了，记得第一次看到spring cloud居然有那么多子项目时，有点被吓到了。开始怀疑自己是否真的可以掌握这么多项目，是否可以将它们都熟练的使用起来，虽然在公司也会使用部分技术进行开发，但是更多的时候都是在做crud。

更何况随着微服务的发展，spring cloud的技术栈更新的特别快，面对这种情况有时真的感到力不从心。当我刚准备开始研究eureka和zuul时，它们居然已经停止更新了，只能怪自己太懒了。技术在不断的进步，而我却懒的动手和纠结于微服务中涌现出的新概念。配置中心、服务注册与发现、网关、客户端负载均衡、日志追踪、断路器。。。

虽然看了很多这方面的文章和书籍，但是各种概念在脑中依然有些模糊，因此打算写下这篇文章，将自己对于微服务和sping cloud关系的理解整理一下，方便以后复习。

2.永远不会改变的请求

请求，顾名思义，因为需要某些东西而向某个事务发出申请。互联网中时时刻刻在产生这请求，我们已最简单的一次登录请求为例开始讲述。首先用户在页面上输入用户名和密码，浏览器生成请求地址：http://ip:port/path/payload，服务器接收并处理请求，将处理之后的结果返回给浏览器。

3.单体时代

在这个时期，互联网的流量并不大，通常一台服务器就可以支撑起来所有的请求，因此前后端都是放在同一台服务器上的。那会儿流行的技术栈是spring+struts2+hibernate+jsp，其中jsp就负责了前端的界面展示，通过jquery技术就可以搞定绝大部分的界面了。

假设服务器部署在本地，那么那会儿发送的登录请求可能是这样的：http://localhost:8888/demo/login/username=zs&password=123

4.前后端分离

随着互联网的不断发展，技术也在持续的进步，人们对界面的要求越来越高，他们觉得模板引擎技术在后端渲染页面再返回速度实在是太慢了，而且样式也很丑。因此他们提出将渲染工作放在浏览器上，这样可以大大的提高访问速度，而且对于前端界面应该也通过工程的方式管理起来。将界面相关的逻辑和业务完全分离开，前后端通过json的方式传递数据，随着这个概念的出现并不断发展后，前后端就彻底分离了。

但是前后端分离以后出现了一些问题，浏览器为了安全考虑新增了同源策略，以前前后端部署在一台机器上并不会出现问题，当前端也以工程的方式管理以后，前端项目也会独自占用一个端口，此时会出现这种情况，后台提供的登录接口为：http://localhost:8888/demo/login/{payload}，前端页面的访问路径为：http://localhost:9999/login.html，此时因为端口不一致导致出现了跨域，有多种方式可以解决跨域问题。

5.分布式部署

当业务量超过一定程度时，仅靠一台机器已经支撑不住了，此时需要将后端业务进行拆分，将拆分后的部分单独部署在一台或多台服务器上。假设进过拆分后恰好将登录服务拆到了A服务器和B服务器上，此时A在处理登录请求时需要B上服务的帮助，它们之间通过RPC的方式通信，RPC框架有Dubbo、netty、mina。。。

6.微服务模式

随着技术的继续演进，出现了一种将功能按照服务拆分，独立开发与部署，服务间通过rest+json方式通信的新概念，在这种模式下一个请求的经历变成了这样：

1.依旧是前后端分离，此时浏览器的请求可能是这样的：http://requestname/login/{payload}，然后浏览器将请求发给了后端，并等待接收响应

2.浏览器并不知道它的请求并没有发送给真正的后端，而是被其他服务拦截了，这个服务的名字叫网关，它会监听所有从浏览器发起的请求。在它的配置文件中写了几条规则，其中一条就是如果请求的名字是以requestname开头的，那么网关就要将请求拦截，做一些个性化定制以后在重新发送，经过网关处理的请求可能变为了：http://gateway-request/login/{payload}

3.经过改名的请求接下来会在注册中心中查找名称为gateway-request对应的ip列表，假如发现了多台，则通过某种负载均衡方式选择其中一台，然后将请求ip改为对应的路径：http://111.111.111:8888/login/{payload}

4.当去访问该服务时发现其中某部分需要跨服务器访问，此时会通过代理的方式发送rest请求

5.当rest请求到达另一台服务器并开始处理时，可能会发生处理过程中出现异常，那么这个服务有多种处理方式，比如返回一个默认的错误信息，或者跳转到另一个方法去执行等等

6.当请求结果按照原路返回后，浏览器可能会抱怨服务器工作效率太差了，一个简单的请求居然耗时这么久，它想知道后台每步到底在干什么，它希望下次再发请求时有个工具可以将请求的执行路径记录下来

7.具体的实现方式

微服务只是一种思想和架构模式，具体想要实现上述请求还是需要实实在在的编码才可以，而基于这种模式衍生了许多的框架， spring将这些框架集合起来就形成了spring cloud系列。

在早期版本中网关由zuul实现，对应上面的第2步，第3步中的注册中心由eureka实现，负载均衡由ribbon实现，第4步中的代理发送rest请求由feign实现，第5步出现错误时的处理方式由hystrix实现，第6步记录请求路径由zipkin和sleuth实现。

通过上面可以发现spring cloud未请求的每一步都提供完整的解决方案，但是随着技术的不断进步，势必会淘汰另一些技术，比如上述的注册中心、网关等因为各种原因停止更新或维护了，但是spring cloud立刻使用新的技术栈nacos和gateway代替。

8.总结

因此虽然技术一直在变，但是其本质思想并没有太大的改变，只有掌握了整体大纲和脉络以后才不至于在学习这些新项目的时候迷失自我，也可以有选择性的学习需要用到的技术，对于已经过时的技术可以重点理解其原理。