【SpringCloud】设计原则之前后端分离与版本控制
一、设计原则之前后端分离
在传统的 Web 应用开发中，大多数的程序员会将浏览器作为前后端的分界线
将浏览器中用户进行页面展示的部分称之为前端，而将运行在服务器，为前端提供业务逻辑和数据准备的所有代码统称为后端
由于前后端分离这个概念相对来说刚出现不久，很多人都是只闻其声，不见其形，所以可能会对它产生一些误解，误以为前后端分离只是一种 Web 应用开发模式，只要在 Web 应用的开发期进行了前后端开发工作的分工就是前后端分离
其实前后端分离不只是开发模式，而是 Web 应用的一种架构模式
在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试
在运行阶段前后端分离模式需要对 Web 应用进行分离部署，前后端之前使用 HTTP 或其他协议进行交互请求
前后端分离原则，简单来讲就是前端和后端的代码分离，也就是技术上做分离
推荐的模式是直接采用物理分离的方式部署，进一步进行更彻底的分离
不要继续使用以前的服务端模板技术，比如 JSP，把 Java JS HTML CSS 都堆在一个页面里，稍复杂的页面就无法维护
这种分离模式的好处：
- 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好
- 分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护
- 前端多聚道集成场景更容易实现，后端服务无须变更，采用统一的数据和模型，可以支撑前端的 Web UI / 移动 APP 等访问
前后端分离意味着前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互
从此，后端使用的技术栈不影响前端
前后端分离并非仅仅只是前后端开发的分工，而是在开发期进行代码存放分离、前后端开发职责分离，前后端进行独立测试；在运行期进行应用部署分离，前后端之间通过 HTTP 请求进行通信
前后端分离的开发模式与传统模式相比，能为我们提升开发效率、增强代码可维护性，让我们有规划地打造一个前后端并重的精益开发团队，更好地应对越来越复杂多变的 Web 应用开发需求
前后端分离的核心：后台提供数据，前端负责显示
二、设计原则之版本控制
在团队的内部，尤其是 API 设计优先的微服务架构中，接口的版本管理显得尤其重要
微服务的一个主要优势是，允许服务独立地演变
考虑到微服务会调用其他服务，这种独立性需要引起高度注意，不能在 API 中制造破坏性更改
接纳更改的最简单方法是绝不破坏 API
如果遵循稳健性原则，而且两端都保守地发送数据，慷慨地接收数据，那么可能很长一段时间都不需要执行破坏性更改
当最终发生破坏性更改时，可以选择构建一个完全不同的服务并不断退役原始服务，原因可能是领域模型已进化，而且一种更好的抽象更有意义
如果对现有服务执行破坏性的 API 更改，应决定如何管理这些更改：
- 该服务是否会处理 API 的所有版本？
- 是否会维护服务的独立版本，以支持 API 的每个版本 ？
- 服务是否仅支持 API 的最新版本，依靠其他适应层来与旧 API 来回切换？
在确定了困难部分后，如何在 API 中反映该版本是更容易解决的问题
通常可通过 3 种方式处理 REST 资源的版本控制：
- 将版本放入 URI 中
将版本添加到 URI 中，这是指定版本的最简单方法。它的优点是非常容易理解，容易在微服务应用构建服务时实现，与 API 浏览工具和命令工具兼容。如果将版本放在 URI 中，版本应该会应用于整个应用程序，所以使用 /api/v1/accounts 而不是 /api/account/v1
- 使用自定义请求标头
可以添加自定义请求标头来表明 API 版本。在将流量路由到特定后端实例时，路由器和其他基础架构可能会考虑使用自定义标头。但是，此机制不容易使用，原因与 Accept 标头不容易使用相同。此外，它是一个仅适用于应用程序的自定义标头，这意味着使用者需要学习如何使用它
- 将版本放在 HTTP Accept 标头中，并依靠内容协商
Accept 标头是一个定义版本的明显位置，但它是最难测试的地方之一。URI 很容易指定和替换，但指定 HTTP 标头需要更详细的 API 和命令行调用
参考资料：《微服务架构实战》—— 张锋
一 叶 知 秋，奥 妙 玄 心