加入收藏 | 设为首页 | 会员中心 | 我要投稿 上饶站长网 (https://www.0793zz.com.cn/)- 数据库平台、视觉智能、智能搜索、决策智能、迁移!
当前位置: 首页 > 云计算 > 正文

云原生架构实施路线图解析

发布时间:2022-06-20 04:45:03 所属栏目:云计算 来源:互联网
导读:云原生架构体系内容众多,如果深入到微服务、容器、 DevOps、服务网格ServiceMesh、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多的工作需要做。比如说微服务,一套SpringCloud开发框架就需要很多的学习成本,更别说还有很多其他的框架、方法和
  云原生架构体系内容众多,如果深入到微服务、容器、 DevOps、服务网格ServiceMesh、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多的工作需要做。比如说微服务,一套SpringCloud开发框架就需要很多的学习成本,更别说还有很多其他的框架、方法和思想,比如微服务的拆分领域驱动设计DDD方法等。
 
  云原生这么多的内容做不到一步到位,而且彼此之间也存在着先后次序相关性,它需要通过一系列的项目持续完成相关的能力,从而实现云原生融合架构。由于云原生架构体系内容众多,需要对其有相对深入的理解并能根据企业实际做出实施顶层规划,然后以分步实施的方法边建设边交付价值,使整个体系建设具备可持续性。
 
  1. 步骤一:微服务采用及运行环境构建
  云原生架构体系中,应用是交付业务价值的载体,而微服务是构建业务应用的技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行。
 
  基于容器技术和容器调度管理技术如Kubernetes构建企业内私有容器云平台支撑微服务应用系统的部署、运行和管理,实现微服务运行时环境支持,基于容器云平台可以实现相关的自服务敏捷能力,比如弹性扩展、服务路由、分发限流、健康检查、错误隔离、故障恢复、资源调度等。
 
  笔者基于实践提出了“主数据驱动设计”的微服务设计方法,主数据本来就是系统间共享的高价值数据,基于企业主数据设计的微服务天然具备系统间的可重用性。而且基于行业通用数据模型(Comm on Data Model,CDM)则很容易定义并完善主数据微服务,减少重复的迭代设计和实现。
 
  2. 步骤二:服务管理和治理
  微服务架构在分解应用的同时也带来了微服务数量的成倍增长,使服务的管理和治理难以通过人工完成。随着微服务量的增加,需要完善服务的管理和治理能力。在完成容器云平台运行时支撑建设之后,可以侧重实现服务的治理和 API的定义,以支持高效的管理和敏捷的服务编排响应,同时实现基于 API的协同。
 
  云原生以API为协同方式,因此在公司内部可以实现容器云平台和 API网关两层的服务治理能力。同一个微服务可以通过 API网关暴露为不同的 API,或者也可以多个微服务暴露为一个 API。API既可以面向企业内部,也可以面向外部生态伙伴。
 
  3. 步骤三:持续交付及安全
  前两个步骤完成了微服务运行运营的基础能力,具备了支撑微服务弹性扩展、协同交互的能力。有了部署运维平台和服务管理治理能力,则就可以侧重提升研发端的持续交付能力。这样,无论开发多少微服务,在服务管理和治理方面也就没有了后顾之忧。以DevOps理论为指导,构建持续集成、持续部署、持续交付、持续监控、持续反馈的闭环流程。
 
  比如说用开源工具,持续集成和持续交付流程涉及开发、源码管理、源码检查、单元测试、用例管理、构建、安全测试、交付管理等众多的工具,仅考虑打通这些工具的认证权限管理,就不是一件容易的事。因此有些DevOps厂商直接自研持续集成、持续交付等流水线。如果具备这样的研发能力,笔者建议尽可能自研或者合作研发,这也是为系统融合打好基础,避免众多的开源第三方工具带来众多的集成问题,难以有效融合在一起。
 
  认证和权限是DevOps体系中的基础安全措施。代码安全检查、镜像安全检查、系统安全、应用安全、接口安全、容器安全等等都需要在 DevOps工具链和流水线实施和使用过程中逐步完善,以提升云原生的整体安全性。
 
  4. 步骤四:自服务敏捷响应基础设施
  基础设施在第一步搭建容器云平台和微服务的时候就会用到,只不过这个阶段微服务量相对较少,对自服务敏捷响应基础设施没有迫切需求。随着持续交付能力的提升,微服务量的增长,运维能力需要从量变演化到质变。自动化、自服务敏捷响应能力提上日程。
 
  基础设施大致可以划分为三个部分:基础设施资源、支撑平台和纯技术工具。基础设施资源可能有很多种异构资源和云平台,需要通过统一的层次(比如多云管理平台)来封装,提供统一的基础设施资源服务,隔离底层异构资源细节,简化应用资源调度。支撑平台主要是微服务开发、运行、运维的平台,例如 持续交付平台、容器云平台等。纯技术工具指的是和业务无关、围绕支撑平台周边的工具,比如消息平台( RabbitMQ、Kafka )、监控平台、权限管理平台、认证平台、人脸识别平台等等。这些平台可以提取构建技术中台能力,各业务应用都可以复用这些能力。
 
  这个过程中,组织架构可以同步调整,比如基础设施资源团队来运维运营基础设施资源,为平台和工具提供资源服务;平台团队来运维运营平台,工具团队来持续研发工具和技术中台服务,支撑以应用管理为中心的架构;应用研发团队专注于业务应用微服务的研发,使用自服务的资源、平台、工具实现服务的研发、测试、部署、运行、运维等全生命周期管理。

(编辑:上饶站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读