加入收藏 | 设为首页 | 会员中心 | 我要投稿 我爱故事小小网_铜陵站长网 (http://www.0562zz.com/)- 视频终端、云渲染、应用安全、数据安全、安全管理!
当前位置: 首页 > 云计算 > 正文

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

发布时间:2022-07-02 13:13:02 所属栏目:云计算 来源:互联网
导读:云原生架构体系内容众多,如果深入到微服务、容器、 DevOps、服务网格ServiceMesh、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多的工作需要做。比如说微服务,一套SpringCloud开发框架就需要很多的学习成本,更别说还有很多其他的框架、方法和
  云原生架构体系内容众多,如果深入到微服务、容器、 DevOps、服务网格ServiceMesh、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多的工作需要做。比如说微服务,一套SpringCloud开发框架就需要很多的学习成本,更别说还有很多其他的框架、方法和思想,比如微服务的拆分领域驱动设计DDD方法等。
 
  云原生这么多的内容做不到一步到位,而且彼此之间也存在着先后次序相关性,它需要通过一系列的项目持续完成相关的能力,从而实现云原生融合架构。由于云原生架构体系内容众多,需要对其有相对深入的理解并能根据企业实际做出实施顶层规划,然后以分步实施的方法边建设边交付价值,使整个体系建设具备可持续性。
 
 
 
    图 1 云原生融合架构实施步骤
 
  根据云原生架构体系中技术之间的关系和实际经验,基于“顶层规划+分步实施”的原则,云原生架构实施路线图我们定义为5个步骤:
 
  微服务采用及运行环境容器云平台构建;
  服务管理和治理;
  持续交付及安全;
  自服务敏捷向基础设施建设;
  增强生产环境韧性和安全性。
  每个实施步骤又可以根据实际建设需要分为若干个子项目,并可能需要多次迭代。比如说,步骤一微服务采用及运行环境构建,容器云平台建设和系统微服务架构采用可能需要分别以不同的项目立项。容器云平台作为基础设施平台,可能还需要规划采购服务器、存储、网络设备等,也可能需要根据微服务系统改造进度持续进行采购。微服务的设计开发就是个持续的过程,可能涉及不同系统的新建或改造重构。同时呢,也可能需要前期的咨询、规划指导和培训等 。不同的单位实际情况不同,所采取的步骤和方式也会不同。
 
  1. 步骤一:微服务采用及运行环境构建
  云原生架构体系中,应用是交付业务价值的载体,而微服务是构建业务应用的技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行。
 
  基于容器技术和容器调度管理技术如Kubernetes构建企业内私有容器云平台支撑微服务应用系统的部署、运行和管理,实现微服务运行时环境支持,基于容器云平台可以实现相关的自服务敏捷能力,比如弹性扩展、服务路由、分发限流、健康检查、错误隔离、故障恢复、资源调度等。
 
  以云应用12或15要素为指导设计微服务。当前微服务分拆的方式通常是基于 领域驱动设计(DDD)方法。不过DDD 对业务领域的划分往往难以清晰定义领域边界,存在着领域划分不合理、数据同时存在于不同领域的问题,为每个服务选择合适的责任级别及其范围是困难的,需要极深的经验和对业务的理解。
 
  因此Martin Flowler建议可以先建一个传统的大一统系统,在对领域知识有更好的了解以后,再通过重构将其改造成微服务。笔者觉得DDD通过领域划分可以在一定程度上简化业务关系,从而简化微服务设计,但 领域划分也使每个领域缺乏全局认识,所以DDD更像是一种分类简化的设计方法, 这会造成多次的重复迭代,造成浪费。而Martin Flowler的建议则使DDD有了全局的视角,能够从上到下,全局来看到领域划分和设计,但这个大一统系统并不容易建设。
 
  笔者基于实践提出了“主数据驱动设计”的微服务设计方法,主数据本来就是系统间共享的高价值数据,基于企业主数据设计的微服务天然具备系统间的可重用性。而且基于行业通用数据模型(Comm on Data Model,CDM)则很容易定义并完善主数据微服务,减少重复的迭代设计和实现。
 
  2. 步骤二:服务管理和治理
  微服务架构在分解应用的同时也带来了微服务数量的成倍增长,使服务的管理和治理难以通过人工完成。随着微服务量的增加,需要完善服务的管理和治理能力。在完成容器云平台运行时支撑建设之后,可以侧重实现服务的治理和 API的定义,以支持高效的管理和敏捷的服务编排响应,同时实现基于 API的协同。
 
  微服务治理有多种实现的方法。基于容器云平台可以直接利用k 8s的能力实现服务的注册发现、配置、路由分发、负载均衡、弹性扩容等,不过容器云平台要作为企业级应用支撑平台,需要在Kubernetes之上扩展实现服务的管理和治理能力。CNCF推荐用 ServiceMesh,代理东西向流量,支持跨语言。Porvital的 SpringClou d框架提供了相对完整的服务治理实现,比如服务的注册发现、配置、熔断、客户端负载均衡等,但仅支持Java;等等有众多的框架和技术 。
 
  微服务架构提出的一个主要目的就是通过API来屏蔽开发语言,无论用什么开发语言,只要遵循同样的 API,都可以进行协同。其实这类似于地球上不同国家之间的交流,通过相互可以理解的公共语言就可以对话。因此在实现服务治理时需要考虑跨平台能力以及对内和对外 API服务能力。这里要区分下微服务的 API和对外的 OpenAPI ,可以看作是两个层次 。OpenAPI通常是跨平台、跨企业的,用于构建生态系统,不过企业内部也可以用于构建企业内部生态。思想都是一样。
 
  云原生以API为协同方式,因此在公司内部可以实现容器云平台和 API网关两层的服务治理能力。同一个微服务可以通过 API网关暴露为不同的 API,或者也可以多个微服务暴露为一个 API。API既可以面向企业内部,也可以面向外部生态伙伴。

(编辑:我爱故事小小网_铜陵站长网)

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

    热点阅读