如何将后端baas化(baas替代后端程序员)

如何制作后端BaaS？针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的小伙伴找到更简单易行的方法。

事实上，BaaS的核心是将我们的后端应用封装到RESTful API中，然后提供外部服务。为了使后端应用程序更容易维护，我们需要将后端应用程序分解成免维护的微服务。

微服务的拆解和合并有一个需要把握的度，因为拆解和合并的过程是有成本的。如果我们拆解得太仔细，必然会导致我们通话环节的增长。当呼叫链路变长时，首先会影响的是网络延迟。这很容易理解。毕竟，如果你离得很远，可能会发生交通堵塞的地方会更多。其次，随着运维成本的增加，呼叫链路越长，整个链就越脆弱，因为如果一个环节出现问题，整个呼叫链的接入就会失败，我们检查问题的难度也会变大。

另一方面，如果我们拆解得太粗糙，调用链接会很短，但这种微服务的可重用性会很差，更不用说高耦合带来的数据库表结构复杂冗余，让我们后期维护起来很困难。我画了一幅画。感受一下。

拆之

那我们就要合理拆除微服务。我们应该如何拆除微服务？其实我上节课提到，目前主流的解决方案是领域驱动设计，也叫DDD。DDD是埃里克埃文斯在2004年的同名书中提出的一个想法，但它一直局限在Java的圈子里。直到2014年，微服务兴起后，才发现它可以指导微服务的拆分，进入了大多数人的视野。总之，DDD是一种方法论：通过对业务分层抽象，分析定义出领域模型，用领域模型驱动我们设计系统，最终将复杂的业务模型拆解为独立运维的领域模型.

其实在使用微服务开发的过程中，我发现微服务作为一个整体应该是一个动态的网络结构，它会随着业务的发展而变化。DDD可以帮助我们在前期分析更好的网络结构，但实际上，我们更应该思考如何从整体上优化动态网络：减少核心节点，保护核心节点，降低网络深度等等.

如何理解动态网络优化？我们可以做一个思维实验：假设我们把所有的功能拆解成微服务，任何一个微服务节点都可以互相调用，调用的频率越高，它们就越接近。那么我们来考虑一下，当我们网站的访问请求流稳定时，我们整个微服务节点的网络状态是怎样的？

首先，网络节点的相互制约，总会让那些相互强依赖、高度耦合的节点越走越近，最终聚集成一组节点。其次，那些与业务逻辑无关的节点逐渐被边缘化甚至消失。让我们看看这些聚集在一起的节点。如果集群中的节点距离太近，实际上不适合拆分，应该整体做成微服务。在这些彼此过于接近的节点组被合并成一个微服务节点之后，我们可以查看那些彼此不太接近并且是微服务的节点。

因此，当我们开始项目时，我们不必太担心如何拆除微服务。相反，我们应该继续关注和考虑每个微服务节点的合理性。就像看动态网络一样，不断调整优化去掉核心节点。最终会伴随你业务的发展阶段，达到各阶段稳定动态的网络结构。

00-1010正如我们上面看到的，被拆解的架构是一个动态的网络，那么我们应该如何合并或者安排呢？当然，和SFF一样，可以通过数组或对象处理的方式处理每个HTTP数据的请求结果，然后返回这些结果。但是在这里我想给大家介绍另一种编排思路，工作流程。

我们可以把用户的要求想象成我们的呼吸系统，我们的肺是SFF，微服务和FaaS节点都是需要氧气的器官。我们深呼吸，氧气进入肺部，血液循环依次让氧气流过我们每个器官，这就是请求环节。一旦每个器官接受到新鲜血液，它就会吸收氧气并返回二氧化碳。最后，血液循环将二氧化碳带到肺部并呼出。这是数据返回链接。我们的器官是通过新鲜血液连接在一起的。这是事件流，即一个事件用于串联FaaS或微服务。

合之

实际上，FaaS提供的安全保护通常是放在扳机上的。触发器的授权类型或验证方法可以设置为匿名或函数函数。匿名是指匿名用户无需签名认证即可访问；函数方法需要签名验证[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. 代码正式上线，灰度环境替换正式环境。流水线的每个节点产生的结果，都会作为下一个节点必要的启始参数。

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

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

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

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

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

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

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

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

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

关于怎样将后端BaaS化问题的解答就分享到这里了，希望