1.1、借助模型工具,画出对架构的理解,从历史演变开始,到目前落地的、较成熟的架构,描述出对它的理解。通过历史演变,我们知道为什么用这个架构,用这个架构有什么好处,如果我们继续延伸的时候,我们如何去实现“易插拔”的理想状态。以下文章仅仅是个人理解,难免存在错误。
应用程序需要部署在大型的服务器上,DB存放在一台服务器上。
思考一下,如果,一台应用程序不够用了,或者一台DB不够了,这时候需要增加DB的服务器。那么,发过来的请求,需要转发给哪一台服务器呢?这就有了负载均衡。多台服务器应用程序,多态db,部署多个服务器软件,分布在不同地域的用户,使用负载均衡,将请求转发至离他们最近的或者最快的服务器上。那么问题来了,如果请求的时候,如果请求过多,用户一直请求,服务器应用程序却请求不了怎么办?这就需要熔断器;
陆续出现熔断器、鉴权的机制,怎么去管理呢?
这时候就是往微服务的模式转变了,这时候,就出现了注册中心,帮助开发者去管理这些熔断器、鉴权模块等。
由单体服务器慢慢演变,其实需要一个很复杂个过程,上述的过程,仅仅是一个梗概;
首先先描述一下前后台的关系;
我们假定前端用vue.js实现,后端用Spring Cloud实现,前端的转发使用Nginx来给后端转发。
Nginx的配置文件,我们可以在/etc/nginx/nginx.conf(一般是这个配置文件,有些可能自定义的,被主配置文件引用)查看。在Nginx的配置文件里,我们可以读取前端项目所在的服务器host和端口,以及files的位置,并且,请求后端的地址也会在这里体现,这样就能够解释通了,我们的请求从浏览器发出,找到前端工程的地址,请求由Nginx反向代理到后端的项目中。