为此，TGO 鲲鹏会专访了时速云联合创始人兼 CTO 王磊，请他来分享时速云 PaaS 平台的整体架构及核心技术、遇到的问题和解决方案、以及如何搭建高效创新的技术和产品团队。
王磊，曾是 IBM 中国开发实验室资深软件工程师，IBM BPM 产品开发组团队负责人，现负责时速云企业级容器 PaaS、DevOps、微服务治理等多个产品、平台及相关解决方案的技术架构、设计和研发管理工作。对容器、Kubernetes 及相关生态技术有较深入理解和研究，致力于通过云计算为企业构建新一代以应用为中心的云原生技术平台。
王磊：目前时速云的产品体系包括企业级容器 PaaS 平台、DevOps 应用交付平台和微服务治理平台，而且结合平台的特点和扩展能力，快速地为合作伙伴的中间件提供云端支撑，比如 BPM、BI、分布式数据库、大数据等相关工具或者产品。
产品整体功能架构
在产品、平台的核心技术或优势上，主要有以下几方面：
- 对 Kubernetes 部署方式的改善，可以一键部署安全的 Kubernetes 集群，并最大程度保证环境的高可用，相对原生方案部署更简单，可用性更高；所有服务组件都以容器化的方式运行，便于管理、升级，可维护性更好。
- 操作系统及 Kubernetes 的相关调优，对系统组件资源调配和节点资源预留的把控，保障节点和服务的长时间稳定运行，并经过了多个客户生产环境复杂场景下的各种考验。
- 通过 Kubernetes 模型 + 控制器的友好扩展方式，实现了对数据库、缓存、消息队列以及第三方产品的完整生命周期管理，包括创建、集群维护、监控告警、健康监测、配置管理、数据备份恢复、运行指标监控等，由系统按照用户的要求维护其期望状态。
- 基于 Kubernetes 自研 DevOps 产品体系，使 DevOps 和 PaaS 具备同样的架构背景和技术体系，任何 PaaS 层的经验积累都可以用来在 DevOps 平台上进行运用和创新；提供一致的数据视图，构建任务产生的日志、监控、告警等数据均可以由 PaaS 层统一管控。
- 在微服务治理方面，实现对 Spring Cloud、Dubbo 等多种微服务框架的融合，减少平台和框架能力之间的冲突，简化工具本身的复杂性；对框架本身进行定制和扩展，满足服务治理层面更丰富的需求。同时，我们开发了云服务总线，用于实现 API 发布订阅、授权、监控和协议转换等能力，也包括 WebService 和 Restful 之间的转化，能够将传统 ESB 上的服务接入，进行统一管理监控，可以作为传统服务向微服务转换的过渡支撑平台。
此外，我们非常注重技术和产品之间的平衡，不断打磨产品设计和用户体验，尽量减少技术门槛的引入。
王磊：目前正处于 v3.2 和 v4.0 并行紧张开发过程中，产品的研发和技术创新，简单来说有以下几个驱动力：
- 以市场需求为导向，同客户进行深入交流，挖掘实际场景下对产品的需求，结合新的技术来满足需求或者解决问题，这其中就会有很多的创新点。
- 挖掘产品层面可优化的点，努力将产品功能、体验做到极致。
- 不断跟进社区、生态中的相关技术发展，对产品能力进行快速的开发、迭代和转型，通过新技术推动自身产品和用户业务场景中的创新。
此外，我们还建立了完备的研发战略决策体系、高效的研发流程、人才培养机制等，也会继续加大研发投入，为企业提供更好的产品和服务，助力企业数字化转型。
王磊：在打造云原生应用平台的过程中，我们也逐步形成了自己的自动化运维产品体系，并在内部研发部门和企业中都得到了很好的应用实践。具体可以从用户服务、节点、集群、平台等多个维度展开，同时在不减少功能和服务质量的同时，对系统逐步进行简化与技术融合：
- 服务层面包括故障自愈能力，自定义探针，灰度发布，打散热点二次调度，横向 / 纵向的伸缩，基于监控和日志的告警及行为策略等；通过模型 + 控制器的方式对集群模式的服务进行自动化管理，提供声明式的资源接口，并由系统维护其期望状态。
- 节点层面涉及到驱赶策略、自动垃圾回收、故障摘除、运维升级等能力。
- 集群层面包括日志监控数据的定期清理，平台资源的弹性伸缩，升级、迁移或者故障恢复的工具支撑。
- 平台层面涵盖系统服务、集群系统组件的监控告警及默认行为策略，相关数据的定时备份及故障恢复；可对历史健康指标进行回溯，统计平台各个服务的 SLA。
- 构建基于 Kubernetes 的 DevOps 服务，统一数据及管理运维方式。
- 将微服务框架同 Kubernetes 进行融合，简化系统复杂度和降低管理运维成本。
k8s 及容器生态已经带来了很多新的理念和技术，我们也在围绕 k8s 进行很多自动化运维的相关工作，也希望新技术、新框架的管理运维工作也可以围绕 k8s 展开，既可以构建通用的自动化运维工具和方法，也可以实现各类数据指标的统一收集，为后续 ChatOps、AIOps 打下工具和数据基础。
王磊：容器 PaaS 从 2015 年初开始技术布道，到吸引众多企业的关注及技术追捧，再到企业的生产环境真正落地应用，也经历了比较长的一段时间，这个过程中也碰到了各种各样的困难。这里从产品技术、市场客户两个方面简单列举一下：
- 初期技术路线的选择，开始一段时间并行尝试 Kubernetes、Mesos 两种方案，以 Kubernetes 为主，半年左右完全停止 Mesos 的相关工作，也让我们比其他厂家少走了很多弯路，有了更多的技术积累，期间也听到一些对 Kubernetes 质疑的声音，过程虽然有一些挑战，但最终我们还是比较幸运的。
- 作为一个偏技术的平台，需要在技术、用户需求、产品之间相互平衡，需要在不偏离产品方向的基础上，用最合适的技术满足企业市场的用户需求。在面对新的用户需求时，开始会是技术和产品分别进行调研设计，避免相互引导、影响，然后再经过讨论确定最终的产品形态，使研发人员逐步养成产品的思维习惯，产品也有了更多的技术背景，长期来看会减少彼此之间不必要的矛盾，更有利于产品创新。
- PaaS 层相对更接近用户的业务系统，所以项目开展过程中难免会接触用户的业务系统，这里面就会涉及到用户应用的配置管理、迁移、改造、各种系统的对接、定制化等相关工作，而这部分的工作根据客户的实际情况可能会带来较高的成本。我们针对不同的场景也逐步积累了一些解决方式，比如在应用迁移时，先整体了解应用的整体架构，尽量将相关服务开发、运维人员聚在一起进行服务容器化和部署调试工作，尤其涉及到跨部门沟通时，前期要做好充分准备工作，必要时再投入研发力量，否则在效率和成本上有很大浪费；在系统对接层面，提供平台完整的 API 文档，在其他平台需要时，可以减少很多的沟通成本。
- 新技术、新理念带来的学习成本，以及技术生态的飞速发展带来的复杂性，都给市场、客户的培养带来了很多成本，需要进行很多技术布道和客户培养工作。客户对新技术的追捧有时甚至超过技术公司的研发速度，也对如何快速运用和管理这些新技术带来了挑战。
- 国内云计算 2B 市场的需求越来越多，同样，进入这个领域的企业也越来越多，竞争日益激烈；而企业在云计算层面还处于初步扩张时期，成熟度还有待提高。在云平台比拼功能（实际使用的功能可能占很少一部分）、抢占市场的大环境下，产品更需要不断的打磨核心能力，在平台可用性、可靠性层面投入更多精力。
王磊：技术层面主要挑战是如何在新技术快速发展、迭代与企业所需稳定产品之间进行平衡，以及进行长远的技术、产品发展方向规划。左手是多样的、复杂的技术生态；右手是各类行业、众多企业的场景化需求，需要运用合适的技术并尽量通过产品化的方式满足特定用户的需求，有时候会比较头疼。
团队层面，构建一个高效的、快速响应市场变化的研发团队，并保持每个成员持续高涨的技术研发热情，是一件很有挑战的事情，尤其是在一个创业型公司中。后续的重点仍然是继续积累技术和行业经验，发挥团队的力量共同打造具备可靠、简单、自动化、集成扩展、协作等特点的容器 PaaS、DevOps 和微服务治理平台，让用户更快捷、安全的进行云原生应用的实践与创新。
王磊：作为一名 CTO，越来越感到这个 title 的不易，从个人履历上看比较简单，技术管理方面在外企作过技术 leader，然后就是在创业公司从 0 搭建目前的研发团队，这里跟大家分享三点：
- 在大公司作技术管理比在创业公司带团队要轻松很多，不同环境下的技术管理方式上会有较大差别。在创业团队，CTO 的首要任务就是招到合适的人，培养技术和产品骨干，使他们尽快成长，成为自己的左膀右臂；其次是技术和产品方向上的把控，在市场上为公司找到最合适的定位，并抢占有利位置，考虑公司业务的可扩展性；再就是研发体系、制度、流程的规范和逐步优化。
- 另外，CTO 的职责随着公司的发展也会有相应的变化，从开始的全栈工程师、架构师、产品经理、技术布道师，到后來的咨询、售前、解決方案，甚至销售工作，基本体验了各种角色的工作，视野越來越宽广，接触的人越來越多。此時把有限的精力花在人员培养、技术方向把控、研发流程优化、提高研发效率等管理工作上，可以带来更大价值。对于技术和管理的平衡，当企业规模和业务复杂度达到一定程度，我认为管理的重要性更大，也值得投入更多的精力，当然，CTO 一定也要拿得起技术，否则只有 CO，可能就会瞎指挥了。
- 花更多的精力放在公司、技术、产品的可扩展性和持续发展上，推荐阅读《架构及未来》学习更多的经验和相关案例，对技术管理者有很大帮助。IT 就是这样一个需要持续学习充电的行业，否则很快就会落伍了，我们需要保持对技术的热情，尤其是对当前或者下一个可能技术热点的学习与探索。
京ICP备14045471号