传统应用向云原生改造的原因

  • 需求响应时间较长
  • 业务创造性不足
  • 服务器运维质量下滑
  • 资源使用存在较大波动，服务器资源利用率较低
  • 用户体量增大，传统服务提供方式较难灵活扩容以满足短期间快速增长的业务需求
  • 缺少统一运维的平台，需要各个开发都能上服务器，导致管控变的异常困难，存在较大安全隐患
  • 缺少审计日志，平台无法对相关操作溯源，如数据删除、更改操作
  • 业务发布、升级困难，投入比较大

  • 数据孤立，数据分析和处理的能力不强

    传统应用改造之路困难重重

  • 老系统需要持续提供服务，新系统需要构建，人力成本、管理成本变高；

  • 新、老系统的同时运维管理成本、压力变大；
  • 无论怎么进行改造，都可能造成短期的企业业务发展受阻；
  • 改造可能会涉及多部门或者团队的协作，甚至有可能侵犯一部分人现有利益，故协作难度不容小觑；

  • 改造后，云应用相关技术存在较大的灰色地带，导致应用的安全性、稳定性无法得到保障，进一步增加了隐患和问题；

    云原生改造方法

  • 开发云原生，基于统一的 PaaS 服务接口编程；

  • 计算云原生，容器、调度（基于资源使用等）、service mesh，降低成本；
    • 降低成本，这里需要注意不是单点的降低，而应该是整体的降低，否则没有意义。比如引入云原生架构，虽然在机器上降了一定成本，但是带来了高管理成本、基础系统建设成本等超过了机器降的成本，这样的架构就成为了鸡肋了。
  • 架构云原生，架构的本质，我认为就是权衡，即成本 VS 受益。
    • 使用现有云原生框架，保障改造效率
    • 思考：开发运维是否极简模式？是否聚焦企业业务？是否实现快速交付？是否减少工作量？
    • 思考：新架构如何与老架构共存，至少共存一段时间？说白了，就是系统的异构怎么实现？比如：虚拟机 VS 容器；
  • 数据云原生