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

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

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

拆之

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

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

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

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

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

合之

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

我们可以将用户的请求想象成我们的呼吸系统，我们的肺就是 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. 代码正式上线，灰度环境替换正式环境。流水线的每个节点产生的结果，都会作为下一个节点必要的启始参数。

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

• 我们的代码合并到指定分支后，通常我会用 Develop 分支。
• Git 的钩子就会触发后续的流水线，开始进入构建打包、测试流程。
• 测试节点做的事情就是跑所有测试 Case，并且统计覆盖率。
• 覆盖率验证通过，代码实例用录制流量模拟验证。
• 模拟验证通过，发布代码实例到灰度环境。
• 线上根据灰度策略，将小部分流量导入灰度环境验证灰度版本。
• 在灰度窗口期，比如两个小时，灰度验证没有异常则用灰度版本替换正式版本；反之则立即丢弃这个灰度版本，止损。

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