泰兴做网站公司,页面设计模板网站,锡林浩特网站建设微信开发,打电话来说做网站_然后答应了一、设计原则之前后端分离
在传统的 Web 应用开发中#xff0c;大多数的程序员会将浏览器作为前后端的分界线
将浏览器中用户进行页面展示的部分称之为前端#xff0c;而将运行在服务器#xff0c;为前端提供业务逻辑和数据准备的所有代码统称为后端
由于前后端分离这个…一、设计原则之前后端分离
在传统的 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 和命令行调用 参考资料《微服务架构实战》—— 张锋 一 叶 知 秋奥 妙 玄 心
