【微服务】大白话，什么是微服务下的前后端开发

什么是前后端分离？

移动互联网时代，为了跨终端，前后端分离就已经开始流行了，应该说有比较成熟的用户基础了。在简易版本的微服务改造中，我们只需要引入接入层网关和开发框架（SpringBoot），前者用于承载前端组件，后者降低开发难度。

接入层网关,通常以Nginx、OpenRestry、Kong等开源中间件为基础扩展，支持从服务治理平台接收控制指令，实现前端热发布和页面级灰度。另外，利用中间件本身的插件机制来实现业务需求定制。

• 前端组件可以采用React、Vue等框架开发，发布时将HTML/CSS/JS等静态资源打成ZIP包。
• 后端组件将服务封装成HTTP RESTful API，发布时打成特定的压缩包，例如：WAR等。
• 前端 UI 部分通过 REST 接口（Http 请求）传入必须的参数， 接收后端返回的数据， 在 UI 层根据预置的操作逻辑、 展现逻辑控制显示的内容。
• 接入层网关会对客户端（浏览器）的请求做路由转发，静态资源请求在本地（终端）处理，动态服务请求转给后端。

前后端分离特点：

​ 1. 交互形式

​ 在前后端分离架构中，后端只需要负责按照约定的数据格式向前端提供可调用的API服务即可。前后端之间通过HTTP请求进行交互，前端获取到数据后，进行页面的组装和渲染，最终返回给浏览器。

​ 2. 代码组织方式

​ 在传统架构模式中，前后端代码存放于同一个代码库中，甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时，都必须把整个项目导入到开发工具中。

​ 3. 开发模式

前后端分离之后，开发流程将如图所示。

​ 4. 数据接口规范流程

在开发期间前后端共同商定好数据接口的交互形式和数据格式。然后实现前后端的并行开发，其中前端工程师再开发完成之后可以独自进行mock测试，而后端也可以使用接口测试平台进行接口自测，然后前后端一起进行功能联调并校验格式，最终进行自动化测试。

前后端分离怎么开发？

不管前端开发框架使用的是 Bootstrap、 jQuery、 VUE、 React 还是 angularjs， 可以将所有前端功能的代码放在一个工程中统一开发、 打包、 部署。 部署的容器可以是原有的 Java 应用容器（Tomcat） 或者是独立的 Web 容器（Nginx、 Apache）。

优势是对 Web 容器的要求不高， 所有前端功能统一开发、 统一管理， 公共类库、 组件统一管理和调用， 系统体积小。

缺点是前端功能代码深度耦合， 容易出现牵一发而动全身的情况。

为了解决这种问题， 前端代码可以按照功能模块进行拆分， 每个大的功能模块一个独立的项目工程， 每部分都可以独立打包、 部署。 虽然公共部分会重复打包， 整体体积变大， 但是可维护性更好， 并且更容易进行功能和部署架构的横向扩展。

初步的“前后端分离” 一般只是代码层面进行了分离， 前端页面代码和后端服务代码还部署在同一个应用容器中（例如 Java 的 Tomcat）。 这种模式的优势是简化了部署的难度和对硬件的要求， 在前端压力增大时还可以灵活的将前端代码进行独立部署， 减轻服务端的压力。

但是后端的压力（不考虑网络带宽），数据量，访问量上来之后随之而来的运算压力，数据库响应，等等，一系列问题都出现了，后端将成为瓶颈，那么这个时候势必延生出另一个趋势，将后端服务拆分化。

但是，拆分成为多个小服务之后，在迭代使用过程中又发生了一系列矛盾。

1. 每个后端服务都是独立的、 无状态的， 自己拥有独立的 CPU 线程、 内存， 如何共享用户的状态信息？
2. 服务之间有依存关系， 如何互相调用？
3. 原来单体集成架构中， 可以很方便的做集群或者多机热备， 当某台服务器宕机后可以快速在多节点进行切换； 现在的微服务架构如何进行服务间的管理， 保证系统的高可用？

第一个问题， 采用 Redis 存储用户的状态信息， 保证用户访问的状态信息可以快速存储和访问； 服务判断请求的有效性， 一般通过 Token 进行验证。往往增加一个Auth认证系统服务， 即用户登陆后， 认证系统即会颁发一个具有有效期限的“Token”， 各个微服务通过验证 Token 的有效性即可确认用户是否是合法登录用户。

第二个问题， 由于每个微服务都是“无状态” 的， 所以采用 REST 模式接口， 通过 JSON 格式传输数据， 采用基于 HTTP 请求的短连接的方式访问服务端接口。

第三个问题， 以 Spring Boot 架构为例， 如果 REST 层使用 Spring Cloud， 则需要引入 Eureka、Zuul 等组件进行自动化的服务发现、 服务管理、 动态路由、 服务监控、 服务故障转移等功能，实现微服务层面的高可用部署。 如果底层服务使用 dubbo， 则需要引入 Dubbo Admin 实现服务发现、 服务管理、 动态路由等功能。

如果存在以下情况之一， 建议采用“微服务”架构； 否则强烈不建议采用，不要为追求微服务而微服务：

• 用户访问量很大。
• 数据量很大。
• 系统功能庞杂， 各个业务模块之间耦合度不高或者可控。

总结

前后端分离并非仅仅只是前后端开发的分工，而是在开发期进行代码存放分离、前后 端开发职责分离，前后端能够独立进行开发测试;在运行期进行应用部署分离，前后 端之间通过HTTP请求进行通讯。前后端分离的开发模式与传统模式相比，能为我们 提升开发效率、增强代码可维护性。