serverless往事 （四）： 空谈架构

空谈往事

好久没更新《serverless往事》了，过完元旦一直没法全心工作，可能也是到了身心的倦怠期。项目的开发也进入平缓阶段；可预见的很长一段时间，架构不会有太大扩展了。说实在，我自身的角色、影响力已经没法支撑项目的扩展了。没有更强大的管理支持，没有更多的资源投入，很多事情只能是空谈。

最近在看《企业IT架构转型之道》，觉得还挺有意思的，这里自来水做个广告。这是一本介绍阿里共享事业部从无到有摸索微服务治理方案的技术文稿。架构师钟华（花名：古谦）讲述了阿里一段波澜壮阔的进化史。力荐。

这期就空谈一下我畅想的架构以作自乐。

现行框架

我们再回顾一下现行架构（有兴趣的朋友可以看我以前的一篇博客Serverless往事（三）：微服务启航）

• 服务提供者（Provider）

  服务提供者指的是实现各个业务模块的应用实例，比如Interview服务，Seninar服务，User服务等等。由于是serverless应用，部署在自动扩容的lambda上，所以并未实现集群部署。

• 服务调用者（Consumer）

  服务调用者其实就是前端的Graphql服务。Consumer通过调用、搜集Provider的消息，为前端提供api操作。

• 配置中心（SSM）

  配置中心其实就是一个叫AWS System Manager: Parameter store的应用：一个简易Key-Value的变量存储工具（一下简称SSM）。在每个Provider部署成功后，会把自身entrypoint存储到SSM中，实现简单的服务注册；Consumer则通过主动拉取SSM的entrypoint发现Provider。

E-pub Architecture

嗯，是一个很乞丐的微服务架构。再看一下数据流：

1. Provider在部署后将entrypoint（或是说自己的url）写入SSM，实现服务注册。
2. 前端调用Graphql服务（Consumer）
3. Consumer主动拉取SSM配置，发现Provider entrypoint。
4. 通过entrypoint调用Provider的rest api

最后Graphql收集、合并Provider的资源后一并发回给前端。

架构很简单，我们只用了两个月的时间就重构了之前的单体应用。目前数个前端应用已经可以共享后端服务了。

但是随着复杂度的增长，这个架构也暴露出了一些问题。最大的不足来自于SSM——它太简单了。

• 除了少数额外的配置，它仅能存储服务地址。事实上，Consumer需要的配置远多于Provider地址，比如版本号、api前缀、认证规则等等。这些规则映射只能通过代码形式写死在Graphql服务里，变成了一个很大的JSON文件。

• Provider要支持多版本，多租户，多套环境（landscape），SSM只能保存一个entrypoint。现阶段我们精简了业务形式，但是一个简单的Key-Value应用显然不能满足持续增长的服务。

• 我们需要一些可以动态配置的规则，比如安全策略、黑白名单、降级熔断的一些条件等等。

• 其他一些我还没有认知的情况。

总之，这个架构扩展性不够，不是一个可持续的方案。

新架构构思

现在进入YY模式……

主流的微服务治理方式自然比我现在的图景丰富很多。我照着前人的模版，自己画了一个架构。基于现阶段已认识到的不足，我幻想了一个未来可能演变到的情景。

服务提供者（Provider）和服务消费者（Consumer）不变，SSM一分为三。业内的大型配置应用过于复杂，一般并不适配serverless，所以我个人更倾向于自己造轮子：写三个lambda，将数据存持久化存储，并附带UI前端。

• 地址服务器（Address Server）：

  地址服务器用于管理服务列表（包括配置中心和规则中心）的地址、版本号、代理等等信息。服务部署后通过rest api自行注册Address服务器，完成一系列地址配置初始化。

• 配置中心（config center）

  配置中心用于代替现阶段Graphql服务里的配置信息，统一管理。Provider启动后自动发布服务最新配置；由Consumer轮询读取配置。

• 规则中心（config center）

  规则中心并不是必需的，只是为用户手动添加的额外规则预留的服务，比如安全策略、黑白名单、降级熔断策略等等信息。手动更新后将自动推送Provider和Consumer。

Architecture YY

最后再规整一下新的调用流程：

• Provider部署后，自动注册entrypoint并发布最新的配置，如①、②所示。

• 前端调用Graphql服务，Consumer动态向地址服务器和配置中心获取最新的Provider信息（如③、④所示），并调用Provider（如⑤所示）。

• 用户可手动制定规则，规则中心实时修改Provider和Consumer限制（如⑥、⑦所示）。

小结

服务扩展后，我们也不免俗套地遇到了新的问题，开发不再是那么顺手。我根据可见的一些困扰，YY了下一阶段的架构，基本上是主流大厂应用的一些策略。至于是否在项目中可行，还有很多现实亟待解决的问题，比如开发经费、人力资源、技术经验、管理水平、组织结构等等。这类事情不是也不该由我一个底层小职员来决定，所以只能YY到这里。

最近在思考一些有趣的话题，生活中我们会遇到很多困扰：有时候会因为无知而畏手畏脚，有时候会因意气之争而刚愎自用；历经心酸往往并不会有所收获，畏手畏脚只得踟蹰不前。回过头来写写网文，逃避一下世俗的反馈倒是能自得其乐。

相关播客

• Serverless往事（一）：从零搭建一个web应用
• Serverless往事（二）：前后端分离
• Serverless往事（三）：微服务启航