2024年11月

Software_Architect.png
多年的运维感悟,什么阶段干什么事。这也是我在内部的运维规范里明确标明,“不提前优化”

我来谈谈几个阶段,

初创阶段

部分参考 原文链接:https://mp.weixin.qq.com/s/vVhLZDL6bRJL9u5GJg63tw

  • 初创阶段,更多关注业务最小模型能否跑通

    • 快速实现
    • 熟悉什么技术栈,就用什么
    • allinone
    • 引入ORM、DAO屏蔽sql复杂性
    • 早期不自研
    • 规模扩大的时候,要浅浅的封装一层,防止日后技术栈更新,控制数量。我称之为“有中台作用,但无中台负重”
    • 只有在开源社区无法满足时,再造轮子
  • 需要容量评估的场景

    • 新系统上线
    • 临时活动、大促、秒杀类
    • 系统容量有质变性增长
  • 创业初期最贵的是时间成本,这个阶段用钱堆资源的方式可以快速解决问题,不贸然重构
  • 有些明显的规则要遵守,比如

    • 不能硬编码IP,使用域名
    • 域名见名知意,区分内外,比如baidu.com / baidu-inc.com
    • 区分生产环境
    • 避免账号公用

步入正轨阶段

  • 这时候就要拆分了,上面提到的allinone可能已经有了性能、容量等压力。此时就要垂直拆分了

    • 核心是基于业务的拆分

      • 代码
      • 数据库、中间件
      • 团队垂直拆分
  • 这时候我们要引入反向代理,最常见的如nginx,我的建议是用更加贴近业务的api网关,比如kong、apisix、openrestry等等,有更多原生功能。如果nginx比作汽车引擎,后者可以比作宝马、奔驰汽车,多了很多配置外,还能开车即用,开箱即用

    • 对应反向代理层也需要高可用,好消息是都是必备能力
  • 服务也要拆分,其中关键的是,尽可能无状态,“状态”尽可能让中间件,redis、mysql、共享存储等手段解决,确保服务动态、快速伸缩

- 阅读剩余部分 -

目标

创建一个具备内部运维知识,识别自然语义,准确调用各种工具执行任务,严格控制幻觉的智能运维工程师。

v0.1 技术方案

方案介绍

使用 OpenAI 的 Assistant 功能,上传知识库,设置提示词。

  • 优势:效果不错,配置简单
  • 劣势:无审计,无法限定回答范围
  • 技术栈:JavaScript/Flowise / Prompt Engineering / OpenAI Assistant

核心内容

Prompt Engineering:

Function Call:通过 Flowise 的自定义工具

v0.1 技术架构

架构图

架构图v1.png

- 阅读剩余部分 -