怎样将后端BaaS化

怎样将后端BaaS化,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

创新互联公司是一家专注网站建设、网络营销策划、微信小程序、电子商务建设、网络推广、移动互联开发、研究、服务为一体的技术型公司。公司成立10多年以来,已经为1000+成都纸箱各业的企业公司提供互联网服务。现在,服务的1000+客户与我们一路同行,见证我们的成长;未来,我们一起分享成功的喜悦。

BaaS 化的核心其实就是把我们的后端应用封装成 RESTful API,然后对外提供服务,而为了后端应用更容易维护,我们需要将后端应用拆解成免运维的微服务

微服务的拆解和合并,都有一个度需要把握,因为我们在一拆一合之间,都是有成本产生的。如果我们拆解得太细,就必然会导致我们的调用链路增长。调用链路变长,首先影响的就是网络延迟,这个好理解,毕竟你路远了,可能“堵车”的地方也会变多;其次是运维成本的增加,调用链路越长,整个链条就越脆弱,因为其中一环出现问题,都会导致整个调用链条访问失败,而且我们排查问题也变得更加困难。

反过来看,如果我们拆解得太粗,调用链路倒是短了,但是这个微服务的复用性就差了,更别提因为高耦合带来的复杂且冗余的数据库表结构,让我们后续难以维护。我画了个图,你感受下。

怎样将后端BaaS化

拆之

那我们要合理地拆解微服务,应该怎么拆解呢?上节课其实我有提到,目前主流的解决方案就是领域驱动设计,也叫 DDD。DDD 是 Eric Evans 在其 2004 年的同名书中提出来的一个思想,但一直仅仅局限在 Java 的圈子里,直到 2014 年,微服务兴起后大家才发现它可以指导微服务的拆分,这才走进了大多数人的视野。用一句话简单总结,DDD 就是一套方法论:通过对业务分层抽象,分析定义出领域模型,用领域模型驱动我们设计系统,最终将复杂的业务模型拆解为独立运维的领域模型

实际我自己在使用微服务开发的过程发现,微服务整体应该是一个动态网络结构,随着业务的发展,这个网络结构也会发生变化。DDD 能帮助我们前期分析出一个较好的网络结构,但实际上,我们更应该思考的是如何整体优化动态网络:减少核心节点,保护核心节点,降低网络深度等等

怎么理解动态网络优化呢?我们可以做个思维实验:假设我们将所有的功能都拆解成微服务,任意的微服务节点之间都可以相互调用,调用越频繁它们之间的距离就越近。那么我们考虑一下,当我们网站的访问请求流量稳定后,我们整个微服务节点组成的网络状态是怎么样的?

首先网络节点的相互制约总会让那些相互之间强依赖的、高耦合的节点,越走越近,最后聚集成一团节点。其次那些跟业务逻辑无关的节点,逐渐被边缘化,甚至消失。我们看这些聚集成团的节点,如果团里的点聚合太近了,其实是不适合拆分的,它们整体应该作成一个微服务。等这些节点太近的团合并成一个微服务节点后,我们再看那些聚集在一起、又不太近的节点就是一个个微服务了。

所以,我们在启动项目时,不用太过纠结应该如何去拆解微服务。而应该持续关注,并思考每个微服务节点的合理性。就像看待动态网络一样,持续地调整优化,去除核心节点。最终它会伴随你业务的发展阶段,达到各个阶段的稳定动态网络结构。

怎样将后端BaaS化

合之

我们上面已经看到了,拆解后的架构是个动态网络,那我们应该怎么合并或者编排呢?当然你像 SFF 那样通过传统的函数,将每个 HTTP 数据的请求结果通过数组或对象加工处理,再将这些结果返回也是可以的。但我在这里想向你介绍另外一种编排思路,工作流。

怎样将后端BaaS化

我们可以将用户的请求想象成我们的呼吸系统,我们的肺就是 SFF,而微服务和 FaaS 节点就是需要氧气的各个器官。我们吸一口气,氧气进入肺部,血液循环将氧气按顺序流经我们每个器官,这就是请求链路。每个器官一接收到新鲜血液,就会吸取氧气返回二氧化碳,最终血液循环将二氧化碳带到肺部呼出,这个就是数据返回链路。我们的各个器官,就被请求链路通过新鲜血液到来的这个事件串联起来了,这个就是事件流,也就是用一个个事件去串联 FaaS 或微服务。

鉴权

其实,FaaS 提供的安全防护通常是放在触发器上的。触发器的授权类型或认证方式我们可以设置为:匿名 anonymous 或函数 function。匿名方式就是不需要签名认证,匿名的用户也能访问;而函数方式,则是需要签名认证[4],这个签名认证的算法,参数需要用到我们账户的访问秘钥 ak/sk[5],ak/sk 相当于我们云账户的银行卡密码,这么重要的账户信息,我们只能限定在服务端使用,前端代码里绝对不可以出现。

要解决后端互调的安全性,我们用 VPC 或 IP 白名单,都很容易解决。比较难处理的是前后端的信任问题,JWT 正好就提供了一种信任链的解决思路。当然,关于鉴权也有一些云服务商推出了一些更加安全易用的 BaaS 服务,例如 AWS 的 IAM 和 Cognito。

安全性是我们考虑架构设计时重要的一环,因为安全架构设计的失败,会直接导致我们资产的损失。鉴权是识别用户身份,防止用户信息泄漏和恶意攻击使用的。但根据我统计的数据,我们在日常 99% 的问题,都发生在新版本上线的环节。

当我们的项目 Serverless 化以后,代码的质量变得尤为重要。你可以想想,Serverless 化之前,你不小心上线了一个 bug,影响的范围最大也就只有一个应用。但是 Serverless 化之后,如果是核心节点发布了严重的 bug 上线,那么影响的范围就是所有依赖它的线上应用了

不过,你也不用太担心,微服务和 FaaS 都具备快速独立迭代的能力。以前我们一个应用的迭代周期通常要一周到两周。但对于 Serverless 化后的应用来说,每个节点借助独立运维的特性,可以随时随地的发布上线。

综上,我们知道了,微服务和 FaaS 都是快速迭代的,修复问题很快,但我们也不能每次都等问题出现,再去依赖这个能力呀。有没有什么办法可以提前发现问题,保证我们既快又稳?目前软件工程的最佳做法就是代码流水线的发布管道。

发布管道

发布管道的流水线主要有 3 个部分:

  1. 代码发布前的验证,代码测试覆盖率 CI/CD;

  2. 模拟流量回归测试通过,发布到灰度环境;

  3. 代码正式上线,灰度环境替换正式环境。流水线的每个节点产生的结果,都会作为下一个节点必要的启始参数。

怎样将后端BaaS化

我们先看看上图,我来解释下这个流程。

  • 我们的代码合并到指定分支后,通常我会用 Develop 分支。

  • Git 的钩子就会触发后续的流水线,开始进入构建打包、测试流程。

  • 测试节点做的事情就是跑所有测试 Case,并且统计覆盖率。

  • 覆盖率验证通过,代码实例用录制流量模拟验证。

  • 模拟验证通过,发布代码实例到灰度环境。

  • 线上根据灰度策略,将小部分流量导入灰度环境验证灰度版本。

  • 在灰度窗口期,比如两个小时,灰度验证没有异常则用灰度版本替换正式版本;反之则立即丢弃这个灰度版本,止损。

目前规模大一些的互联网公司发布流程基本都在这样跑,如果你不是很了解,可以自己尝试用我们介绍的 Serverless 工作流或者云服务商提供的工作流工具动手搭建下。在这套流程的基础上,很多企业为了追求更高的稳定性,还会设定环境隔离的流水线和安全卡口。比如隔离测试环境和线上环境,测试环境用来复现故障。每次代码进入发布管道,都必须先在测试环境跑通,跑通后安全卡口放行,才能进入线上环境的流水线。

关于怎样将后端BaaS化问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。


新闻名称:怎样将后端BaaS化
网站地址:http://myzitong.com/article/jiodgj.html