分布式前后端分离微服务架构前后端分离分布式

转载

mob6454cc6d1c0b 2024-06-07 13:21:20

文章标签 分布式前后端分离微服务架构前后端分离接口文档数据模板引擎 文章分类 架构后端开发

因为公司以往项目前后端未分离开发，在最近负责的项目中尝试采用前后端分离来提高整体开发效率。

因为写代码资历不是很老，没有经历过更早的时期了，刚毕业SpringMVC和Struts2等架构已经很成熟，所以最早接触的开发方式就是从MVC开发方式开始的，下面我们将开发方式分为未分离，半分离和分离三个时期来做详解。

未分离时期

大致就是所有的请求都被发送给作为控制器的Servlet，它接受请求，并根据请求信息将它们分发给适当的JSP来响应。同时，Servlet还根据JSP的需求生成JavaBeans的实例并输出给JSP环境。需要说明的是，这个View还可以采用 Velocity、Freemaker 等模板引擎。使用了这些模板引擎，可以使得开发过程中的人员分工更加明确，还能提高开发效率。那这种模式存在一些什么问题呢？

1、前端无法单独调试

在项目上线后，遇到一些问题。比如样式出问题了，由于前端不具备项目开发环境，那么就有可能出现如下对话：

前端:"我这里没问题啊。后端，你那里正常么？"
后端:"我这里不正常啊。要不你过来看一下吧?"
前端:"一时我也看不出问题，我也没环境，怎么办？"
后端:"你没环境，坐我这边调吧。"
然后，前端就满脸不爽的在你那调代码了。

总结，因为前端无法单独调试。一方面开发效率降低。另一方面，还有可能引发公司内部人员上的矛盾。

2、前端不可避免会遇到后台代码

比如前端可能碰到如下结构的代码

<body>
 <%
 request.setCharacterEncoding("utf-8")
 String name=request.getParameter("username");out.print(name);
 %>
 </body>

身为前端，在页面里看到了后台代码，必然内心是十分不快的，这种方式耦合性太强。那么，就算你用了freemarker等模板引擎，不能写JAVA代码。那前端也不可避免的要去重新学习该模板引擎的模板语法，无谓增加了前端的学习成本。
正如我们后端开发不想写前端一样，你想想如果你的后台代码里嵌入前端代码，你是什么感受？因此，这种方式十分不妥。当然也可以前端人员开发页面html+css，后端人员从开发那里获取页面html+css，组装成jsp，添加jsp标签+js，放到后端项目中。但是这个流程无疑增加了前后端集成和后期修复问题的成本。

3、JSP本身所导致的一些其他问题

比如，JSP第一次运行的时候比较缓慢，因为里头包含一个翻译为Servlet的步骤。再比如因为同步加载的原因，在jsp中有很多内容的情况下，页面响应会很慢。

半分离时期

前后端半分离，当前我们项目就走在这个阶段，前端负责开发页面，前后端规定好接口文档后，通过接口（Ajax）获取数据，采用dom操作对页面进行数据绑定，最终是由前端把页面渲染出来。这也就是其他博客里说的，Ajax与SPA应用（单页应用）结合的方式。

具体步骤如下:
(1)浏览器请求，nginx返回html页面
(2)html中的js代码以ajax方式请求后台的restful接口
(3)接口返回json数据，页面解析json数据，通过dom操作渲染页面

那这种方式的优缺点呢？

先说优点，首先，这种方式的优点是很明显的。前端不会嵌入任何后台代码，前端专注于html、css、js的开发，有了接口文档后，前后端基本解耦，前端不依赖于后端，减少了前后端人员沟通和集成的成本。自己还能够模拟json数据来渲染页面。发现bug，也能迅速定位出是谁的问题，不会出现互相推脱的现象。前端可以根据nginx或cdn部署自己的程序，实现基本意义上的分离。

当然半分离阶段也是有很多问题。

1、js存在大量冗余，在业务复杂的情况下，页面的渲染部分的代码，会比较复杂。
2、在json返回的数据比较大的情况下，渲染的比较缓慢，业务量大的页面容易出现页面卡顿的情况。
3、seo非常不方便，由于搜索引擎的爬虫无法爬下js异步渲染的数据，导致这样的页面，SEO会存在一定的问题。

分离时期

保险起见，这个阶段项目暂时还没接触过。在这一时期，扩展了前端的范围。认为controller层也属于前端的一部分。在这一时期
前端：负责View和Controller层。
后端：只负责Model层，业务处理/数据等。
可是前端不懂后台代码呀？controller层如何实现呢？
这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。最重要的一点是，前端不用再学一门其他的语言了，对前端来说，上手度大大提高。这个阶段优点很明显。

1、适配性提升

我们其实在开发过程中，经常会给pc端、mobile、app端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。在该结构下，每种前端的界面展示逻辑由node层自己维护。如果产品经理中途想要改动界面什么的，可以由前端自己专职维护，后端无需操心。前后端各司其职，后端专注自己的业务逻辑开发，前端专注产品效果开发。

2、响应速度提升

我们有时候，会遇到后端返回给前端的数据太简单了，前端需要对这些数据进行逻辑运算。那么在数据量比较小的时候，对其做运算分组等操作，并无影响。但是当数据量大的时候，会有明显的卡顿效果。这时候，node中间层其实可以将很多这样的代码放入node层处理、也可以替后端分担一些简单的逻辑、又可以用模板引擎自己掌握前台的输出。这样做灵活度、响应度都大大提升。

3、性能得到提升

我们请求一个页面，可能要响应很多看后端接口，请求变多了，自然速度就变慢了，这种现象在mobile端更加严重。采用node作为中间层，将页面所需要的多个后端数据，直接在内网阶段就拼装好，再统一返回给前端，会得到更好的性能。