面向 “大模型” 的未来服务架构设计

大模型热潮

今年的互联网赛道中 “顶流” 非大模型莫属。 科技部新一代人工智能发展研究中心 5 月底发布的《中国人工智能大模型地图研究报告》显示，我国 10 亿参数规模以上的大模型已发布79个，几乎进入“百模大战”。

百度的文心一言 ，阿里的通义千问、讯飞星火大模型、智谱AI的ChatGLM 等纷纷发布。此后，美团、百川智能、云知声、美图、腾讯……新加入大模型赛道的国内科技公司此起彼伏，一场围绕大模型的 “军备竞赛” 已趋白热化。

大模型落地

ChatGPT 掀起 AI 热之后，微软已经成为这股浪潮中最重要的企业之一。不仅因为其是 OpenAI 的大股东，或者推出 AI 加持的 New Bing。

更重要的是：作为全球第一大操作系统服务商、全球第一大办公软件开发商，以及全球第二大云服务商，微软更是提出 “旗下全部产品将和大模型组件融合，全面拥抱大模型落地。”

中关村论坛2023上，李彦宏以《大模型改变世界》为题，也提出 “百度要做第一个把全部产品重做一遍的公司，不是整合，不是接入，是重做，重构….“

毫不客气的预测，未来的服务将会全部面向或依托 “大模型” 提供产品服务。

那么面向未来 “大模型” 的服务应该如何设计或重构呢/？

服务设计 or 重构

为支持 “大模型” 调用，服务需要重新定位，成为 “底座” 。这里的底座，可理解为 “大模型” 的落脚点：目标数据的吞吐。

强悍的 “大模型” ，重新定义人机交互。 在短时间内分析出用户的诉求，并针对诉求去提供目标服务。现行的，通过用户手动触发 App 静态接口的交互模式被打破，变成了通过 “大模型” AI 化分析诉求后，进行单个或多个目标服务接口的触发，最终汇总、裁剪各服务响应数据，进行服务功能产出。

举个例子：在地图场景中，
客A：帮我规划一下十一北京旅游路线…
地图：北京景点 -> 十一天气 -> 景点评分 -> 景点间合适的浏览顺序编排 -> …

基于这种交互的特征、并结合 云原生中 分布式、微服务等多种技术概念，我们可以对服务进行重构升级或重新设计。

未来的服务架构

微服务化

为了支撑未来 “大模型” 的交互模式，满足各种任意的服务装配、拼装。我们需要将服务进行最小粒度封装，这也延续了微服务的核心思想。

分层化

这里需要注意的是，现行的交互模式依旧存在。我们要用最小的成本，兼并支撑两种交互模式。那就需要引入 “分层” 的设计思路，将不同的交互模式进行抽象、分化为不同的逻辑层。

这里介绍一种模式，如下：

大模型应用架构

架构模式分为 入口层、大模型结果调用层、协议层、业务内聚层、数据访问层、微服务调用层。

架构设计图

如上图中各逻辑层：

• 入口层
  • 完成中间件的注册任务，为后续服务功能提供基础能力支撑。包含
    • 接口 token 鉴权【Sign加盐模式】、
    • 服务异常捕获【Panic Recover 中间件：捕获服务异常，防止主程序 panic】、
    • 监控服务注册【Prometheus 指标采集】、
    • 日志中间件【初始化日志功能，打印访问日志 Access_log 】、
    • Mesh 服务注册【Proxyless Service Mesh 进行流量熔断限流、防调用雪崩…】
• 大模型调用层
  • 为大模型提供 “底座” 能力，基于大模型的产出结果，提供对应服务的 API 调用能力。包含 复合、单协议 两种服务粒度协议
• 协议层
  • 包含复合协议、单协议两种类型，为业务、大模型调用提供内容数据输出。
    • 单协议，针对服务最小粒度封装的 API 接口
    • 复合协议，针对多服务进行拼装后，封装的 API 接口
• 业务内聚层
  • 为复合协议对应的服务聚合层。在此层进行多个服务的串/并编排，对外提供服务聚合数据
• 数据裁剪层
  • 在服务调用层之上，是对每个服务的请求、响应 数据的独立封装
• 微服务调用层
  • 基于多种通信协议，完成服务调用
• 另外分别为 Util 和 Tool 部分
  • 贯穿服务，提供公共能力及可观测、稳定性相关的能力支撑

架构 Demo 实现

//篇幅有限，见后续博文

小结

在竞争日益激烈、全球复杂多变的现状下，企业、团队只有掌握先机，提前布局，才会成为最终的胜者，拥有绝对的敏捷竞争力！

附录

• 五分钟搭建基于 Prometheus + Grafana 实时监控系统
• 千万级入口服务[Gateway]框架设计(三：分层模式)
• 云原生应用架构的迁移 一 ：增量迁移范式