Skip to content

Latest commit

 

History

History
40 lines (30 loc) · 2.96 KB

resolution.md

File metadata and controls

40 lines (30 loc) · 2.96 KB

目标问题

1. 应用开发之下的 devops 问题的整体解决方案

  • 常见问题

    • 面对用户的应用级开发仅仅是冰山一角,在此之下有机房,网络,服务器,系统管理,运维管理,监控,告警,日志,等等一系列背后的工作,而这部份的工作可能比应用级开发还要复杂
    • 采用 IaaS 解决了服务器采购和上架问题,但是依然需要一个强大的 devops 团队来负责上述事务,否则基础设施很容易成为发展瓶颈,且越拖越难解决
    • 上面的这些工作对于每一个产品可能都是同质化但又伴随着定制,会消耗大量的时间做这些重复的工作
  • Lain 是怎么做的

    • 直接在几乎裸的 IaaS 或者服务器上即可构建 lain 集群,方便的进行在线的扩容缩容等集群底层资源操作
    • 整合了业界沉淀下来的良好的大运维整体实践,提供了冰山下的这一大块工作的一揽子解决方案
    • 将纷繁复杂的系统管理和运维管理行为封装为更简单易用的工具包,极大简化大部分的系统工作,降低日常维护的技术门槛和人力需求
    • 将同质化的工作整合在一起,避免重复劳动
    • 开箱即用的各种管理组件,囊括了部署,扩容,监控,告警,日志等方方面面
    • 开箱即用的附赠应用,包括 mysql ,redis 的集群服务

2. 规范了应用开发的 workflow ,并辅以适当的 SCM 支援

  • 常见问题

    • 在个人开发者以及 startup 组织中,良好的 workflow 这件事几乎是不会被提及的,然而在日渐发展的过程中遗留的技术债务却会越来越多的影响开发部署的效率和质量
    • 设计,开发和部署行为的不规范会引发各种血案
  • Lain 是怎么做的

    • 提供本地开发环境的解决方案
    • 提供本地开发过程的 SDK/CLI 工具链,使得开发和构建过程是嵌入在解决方案中的
    • 隐性的提供了 SCM 支援,约束了开发者的开发和发布行为

3. 提高整体资源利用率,优化冗余资源池

  • 常见问题

    • 传统的按照产品线规划资源池的情况下,会给各产品预留专属的资源池以及配备冗余,以便进行灾备以及服务突发流量
    • 然而各产品线的资源需求类型不同,冗余类型也不同,无法共通共享,造成众多的重复冗余,资源利用率比较低
    • 通过服务器资源的冗余,扩容缩容,以及资源迁移的操作比较复杂,时间消耗大,风险高
  • Lain 是怎么做的

    • 通过容器技术的资源隔离和控制,实现多种技术栈多种应用在集群内安全的不相互影响的混合部署,通过统一的资源池进行冗余,有效提高资源利用率
    • 容器技术的运用使得对下资源的使用形成完全统一的形式,扩容缩容以及迁移的成本很低,操作也更简单

4. TBD: 架构上提供了服务治理的可能性和解决方案