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

我来谈谈几个阶段，

初创阶段

部分参考 原文链接：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、共享存储等手段解决，确保服务动态、快速伸缩

- 阅读剩余部分 -