前后端分离是如何做的
在前后端分离架构中，后端只需要负责按照约定的数据格式向前端提供可调用的 API 服务即可。前后端之间通过 HTTP 请求进行交互，前端获取到数据后，进行页面的组装和渲染，最终返回给浏览器。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站！
微信- 支付宝
相关推荐
2022-06-23
微服务与 SOA 的区别
微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。 较早实践微服务的公司 Netflix 就曾经称他们构建的架构是「细粒度的 SOA」。 讨论「微服务和 SOA 的差别」的意义远不如讨论「微服务和单体系统的差别」更大，因为他们的区别实在有点微妙。此外，互联网近些年的发展，越来越朝去中心化的方向前进了，就像今天的IT工程师不需要像律师、教师那样，需要得到某些机构的认可才能更好的开展工作，这一方面意味着门槛的降低，另一方面也意味着更多的概念没有一个权威的声音来对它进行定义，使得每个人可以根据自己的需求做出不同的调整。 微服务和 SOA 都是这样背景下的产物，并没有一个权威的定义，来说明它们各自包含了什么东西，使用什么的方法进行系统的构建。但是，还是可以从最大的范围来对比它们的不同，当我们今天说出这两个概念时，其区别往往没有那么大，但 SOA 是有一定的历史了，在历史上的 SOA 往往意味着更多的东西，而这些是现在很多人在做架构设计时不会采用的。
2022-06-17
说说如何设计一个良好的 API
版本号在 RESTful API 中，API 接口应该尽量兼容之前的版本。但是，在实际业务开发场景中，可能随着业务需求的不断迭代，现有的 API 接口无法支持旧版本的适配，此时如果强制升级服务端的 API 接口将导致客户端旧有功能出现故障。实际上，Web 端是部署在服务器，因此它可以很容易为了适配服务端的新的 API 接口进行版本升级，然而像 Android 端、IOS 端、PC 端等其他客户端是运行在用户的机器上，因此当前产品很难做到适配新的服务端的 API 接口，从而出现功能故障，这种情况下，用户必须升级产品到最新的版本才能正常使用。 为了解决这个版本不兼容问题，在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下，我们会在 url 中保留版本号，并同时兼容多个版本。 【GET】 /v1/users/{user_id} // 版本 v1 的查询用户列表的 API 接口【GET】 /v2/users/{user_id} // 版本 v2 的查询用户列表的 API 接口 现在，我们可以不改变版本 v1 的查询用...
2022-06-21
怎么考虑数据一致性问题
单体应用的数据一致性想象一下如果我们经营着一家大型企业，下属有航空公司、租车公司、和连锁酒店。我们为客户提供一站式的旅游行程规划服务，这样客户只需要提供出行目的地，我们帮助客户预订机票、租车、以及预订酒店。从业务的角度，我们必须保证上述三个服务的预订都完成才能满足一个成功的旅游行程，否则不能成行。 我们的单体应用要满足这个需求非常简单，只需将这个三个服务请求放到同一个数据库事务中，数据库会帮我们保证全部成功或者全部回滚。 当这个功能上线以后，公司非常满意，客户也非常高兴。 微服务场景下的数据一致性这几年中，我们的行程规划服务非常成功，企业蒸蒸日上，用户量也翻了数十倍。企业的下属航空公司、租车公司、和连锁酒店也相继推出了更多服务以满足客户需求，我们的应用和开发团队也因此日渐庞大。如今我们的单体应用已变得如此复杂，以至于没人了解整个应用是怎么运作的。更糟的是新功能的上线现在需要所有研发团队合作，日夜奋战数周才能完成。看着市场占有率每况愈下，公司高层对研发部门越来越不满意。 经过数轮讨论，我们最终决定将庞大的单体应用一分为四：机票预订服务、租车服务、酒店预订服务、和支付服务。服务各自...
2022-06-27
微服务的安全
OAuth 是一个关于授权的开放网络标准，它允许第三方网站在用户授权的前提下访问用户在服务商那里存储的各种信息。实际上，OAuth 2.0 允许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的时间内访问特定的资源。用户在客户端使用用户名和密码在用户中心获得授权，然后客户端在访问应用是附上 Token 令牌。此时，应用接收到客户端的 Token 令牌到用户中心进行认证。 一般情况下，access token 会添加到 HTTP Header 的 Authorization 参数中使用，其中经常使用到的是 Bearer Token 与 Mac Token。其中，Bearer Token 适用于安全的网络下 API 授权。MAC Token 适用于不安全的网络下 API 授权。
2022-06-25
微服务如何进行数据库管理
分布式数据管理之痛点为了确保微服务之间松耦合，每个服务都有自己的数据库, 有的是关系型数据库(SQL)，有的是非关系型数据库(NoSQL)。开发企业事务往往牵涉到多个服务，要想做到多个服务数据的一致性并非易事，同样，在多个服务之间进行数据查询也充满挑战。我们以一个在线 B2B 商店为例，客户服务包括了客户的各种信息，例如可用信用等。管理订单，提供订单服务，则需要验证某个新订单与客户的信用限制没有冲突。在单体应用中，订单服务只需要使用传统事务交易就可以一次性检查可用信用和创建订单。相反微服务架构下，订单和客户表分别是相应服务的私有表，如下图所示： 订单服务不能直接访问客户表，只能通过客户服务发布的 API 来访问或者使用分布式事务, 也就是众所周知的两阶段提交 (2PC)来访问客户表，2PC 意义图如下所示： 这里存在两个挑战： 第一个挑战是 2PC 除要求数据库本身支持外，还要求服务的数据库类型需要保持一致。但是现在的微服务架构中，每个服务的数据库类型可能是不一样的，有的可能是 MySQL 数据库，有的也可能是 NoSQL 数据库; 第二个挑战是如何实现从多个服务中查询数据...
2022-06-19
如何保证接口的幂等性
当通过调用创建实例接口在负载均衡中创建云服务器时，如果遇到了请求超时或服务器内部错误时，客户端可能会尝试重发请求，这时客户端可以通过提供可选参数 ClientToken 避免服务器创建出比预期要多的实例，也就是通过提供 ClientToken 参数保证请求的幂等性。ClientToken 是一个由客户端生成的唯一的、大小写敏感、不超过 64 个 ASCII 字符的字符串。 如果用户使用同一个 ClientToken 值调用创建实例接口，则服务端会返回相同的请求结果，包含相同的 InstanceId。因此用户在遇到错误进行重试的时候，可以通过提供相同的 ClientToken 值，来确保负载均衡只创建一个实例，并得到这个实例的 InstanceId。 如果用户提供了一个已经使用过的 ClientToken，但其他请求参数不同，则负载均衡会返回 IdempotentParameterMismatch 的错误代码。但需要注意的是，SignatureNonce、Timestamp 和 Signature 参数在重试时是需要变化的，因为负载均衡使用 SignatureNonce 来防止重放...
评论
WalineDisqus
