建网站怎么备案,王烨飞微博,godaddy wordpress迁移,生物学特色网站建设简介#xff1a; 云原生是零售云的最重要的技术底座#xff0c;云原生是什么#xff0c;会走向哪里#xff0c;在零售2B交付的场景上该如何应用#xff0c;怎么能够结合帮助建设零售云系列产品体系#xff0c;值得我们的思考和探索#xff0c;也将有效指导我们接下来几年…简介 云原生是零售云的最重要的技术底座云原生是什么会走向哪里在零售2B交付的场景上该如何应用怎么能够结合帮助建设零售云系列产品体系值得我们的思考和探索也将有效指导我们接下来几年的零售云项目和产品建设。
零售云是阿里三朵业务云零售云、金融云和政务云之一将开辟阿里在电商、零售行业的新蓝海2B快速交付、赋能合作伙伴更快业务增长和节省成本。云原生是零售云的最重要的技术底座云原生是什么会走向哪里在零售2B交付的场景上该如何应用怎么能够结合帮助建设零售云系列产品体系值得我们的思考和探索也将有效指导我们接下来几年的零售云项目和产品建设。
云原生定义、阿里巴巴云原生架构方法论及产品体系
云原生定义
Cloud Native 翻译为云原生是 Matt Stine 提出的一个概念它是一个思想的集合包括 DevOps 、持续交付Continuous Delivery、微服务MicroServices、敏捷基础设施Agile Infrastructure、康威定律Conways Law等以及根据商业能力对公司进行重组。Cloud Native 既包含技术微服务敏捷基础设施也包含管理DevOps持续交付康威定律重组等。Cloud Native 也可以说是一系列技术、企业管理方法的集合。
云原生的本质
云原生本质是以应用为中心让应用能最大限度享受到云计算的红利。云原生是云计算的下一站云原生架构是引领未来十年的新一代技术架构。云原生让云计算变得标准、开放、简单高效、触手可及。
云原生应用开发的最佳实践原则12-Factor
1、 基准代码一份基准代码Codebase多份部署deploy
基准代码和应用之间总是保持一一对应的关系一份代码可以部署在开发环境、测试环境、预发环境及产线环境。
多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案如下
将共享的代码拆分为独立的类库然后使用依赖管理策略去加载它们。所有部署的基准代码相同但每份部署可以使用其不同的版本。比如开发人员可能有一些提交还没有同步至预发布环境预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码我们就认为它们只是相同应用的不同部署而已。
2、 依赖——显式声明依赖关系Dependency
12-Factor 规则下的应用程序不会隐式依赖系统级的类库。它一定通过依赖清单确切地声明所有依赖项。大多数编程语言都会提供一个打包系统比如 java 使用 maven 应用依赖了哪些第三方库要显示地定义在 POM 文件里。
3、 配置在环境中存储配置
配置要和代码完全分离环境变量可以非常方便地在不同的部署间做修改却不动一行代码。配置主要包括数据库信息缓存信息第三方服务证书每份部署特有的配置如域名等信息。
判断一个应用是否正确地将配置排除在代码之外一个简单的方法看该应用的基准代码是否可以立刻开源而不用担心会暴露任何敏感的信息。
4、 后端服务把后端服务当作附加资源
后端服务是指程序运行所需要的通过网络调用的各种服务如数据库消息系统及缓存系统。
12-Factor 应用的任意部署都应该可以在不进行任何代码改动的情况下进行后端服务的切换比如将本地 MySQL 数据库换成第三方服务例如阿里云的 RDS。另外部署可以按需加载或卸载资源。例如如果应用的数据库服务由于硬件问题出现异常管理员可以从最近的备份中恢复一个数据库卸载当前的数据库然后加载新的数据库 。整个过程都不需要修改代码。
5、 构建-发布-运行严格分离构建和运行
基准代码 转化为一份部署(非开发环境)需要以下三个阶段
构建阶段将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码,获取和打包依赖项,编译成二进制文件和资源文件。
发布阶段将构建的结果和当前部署所需配置相结合并能够立刻在运行环境中投入使用。
运行阶段(“运行时”)针对选定的发布版本在执行环境中启动一系列应用程序进程。
每一个发布版本必须对应一个唯一的发布 ID,一旦发布就不可修改任何的变动都应该产生一个新的发布版本。另外发布管理工具需要能方便的回退至较旧的发布版本。
6、 进程以一个或多个无状态进程运行应用
运行环境中应用程序通常是以一个和多个进程运行的。12-Factor应用的进程必须无状态且无共享任何需要持久化的数据都要存储在后端服务内比如数据库或缓存。
7、 端口绑定通过端口绑定提供服务
12-Factor应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务并监听发送至该端口的请求。比如在线上环境中请求统一发送至公共域名然后路由至绑定了端口的网络进程。
8、 并发通过进程模型进行扩展
在 12-factor 应用中进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构将不同的工作分配给不同的进程类型。例如HTTP 请求可以交给web进程来处理而常驻的后台工作则交由 worker进程负责。
9、 易处理快速启动和优雅终止可最大化健壮性
12-Factor 应用的进程是易处理的即它们可以瞬间开启或停止。这有利于快速、弹性的伸缩应用迅速部署变化的代码或配置稳健的部署应用。
进程应当追求最小启动时间并且一旦接收到终止信号SIGTERM可以优雅的终止。进程还应当在面对突然死亡时保持健壮例如底层硬件故障。无论如何12-Factor应用都应该可以设计能够应对意外的、不优雅的终结。
10、 开发环境与线上环境等价尽可能的保持开发预发布线上环境相同
12-Factor 应用的开发人员应该避免在不同环境间使用不同的后端服务即使适配器已经可以几乎消除使用上的差异。这是因为不同的后端服务意味着会突然出现的不兼容从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看消除这种阻力需要花费很大的代价。
11、 日志把日志当作事件流
12-factor 应用本身从不考虑存储自己的输出流。不应该试图去写或者管理日志文件。相反每一个运行的进程都会直接的标准输出stdout事件流。开发环境中开发人员可以通过这些数据流实时在终端看到应用的活动。
12、 管理进程:后台管理任务当作一次性进程运行
一次性管理进程主要指一些管理或维护应用的一次性任务比如运行数据迁移运行一些提交到代码仓库的一次性脚本等。它们应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布从而避免同步问题。
以上了解了 12-Factor 应用原则。在我们学习 K8s 的过程中个人认为 K8s 结合service mesh 很好的满足了上面的每条原则。设计 K8s 和 ServiceMesh 的人很伟大提出 12 原则的 AdamWiggins 很伟大。
阿里巴巴云原生架构方法论
阿里巴巴云原生架构设计方法
阿里巴巴独有的云原生架构设计方法——ACNAAlibaba Cloud Native Architecting如下
ACNA 是一个 「41」 的架构设计流程「4」 代表架构设计的关键视角包括企业战略视角、业务发展视角、组织能力视角和云原生技术架构视角「1」 表示云原生架构的架构持续演进闭环。 值得一提的是ACNA 除了是一个架构设计方法也包含了对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等。
另外云原生架构演进是一个持续迭代的过程每一次迭代都是从企业战略、业务诉求到架构设计与实施的一个完整闭环整体关系如下图
阿里巴巴云原生成熟度模型 由 于 云 原 生 架 构 包 含 了 6 个 关 键 架 构 维 度 简 写 为 SESORAService Elasticity Serverless Observability Resilience Automation因此我们先定义关键维度的成熟度级别
阿里巴巴云原生产品体系
阿里巴巴云原生产品家族包括容器产品家族、微服务产品家族、Serverless 产品家族、Service Mesh 产品家族、消息产品、云原生数据库家族、云原生大数据产品家族等。
1、容器产品家族 2、微服务产品家族
EDAS企业分布式应用服务是一个面向微服务应用的应用全生命周期 PaaS 平台产品全面支持 HSF、Dubbo、Spring Cloud 技术体系提供 ECS 集群和 K8s 集群的应用开发、部署、监控、运维等全栈式解决方案。
MSE微服务引擎是一个面向业界主流开源微服务框架 Spring Cloud、Dubbo 的微服务平台 包含治理中心、托管注册 / 配置中心一站式的解决方案帮助用户提升微服务的开发效率和线上稳定性。
ACM应用配置管理是一款应用配置中心产品实现在微服务、DevOps、大数据等场景下的 分布式配置服务保证配置的安全合规。
CSB Micro Gateway微服务网关服务针对微服务架构下 API 开放的特点提供能与微服务环 境的治理策略无缝衔接的网关服务实现高效的微服务 API 开放。
GTS全局事务服务用于实现分布式环境下特别是微服务架构下的高性能事务一致性可以与多种数据源、微服务框架配合使用实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合。
ARMS应用实时监控服务 ) 是一款应用性能管理产品包含前端监控、应用监控和 Prometheus 监控三大子产品涵盖了浏览器、小程序、APP、分布式应用和容器环境等性能管理实现全栈式性能监控和端到端全链路追踪诊断。链路追踪Tracing Analysis为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、 链路拓扑、应用依赖分析等工具能够帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈提高 微服务时代下的开发诊断效率。
PTSPerformance Testing Service是一款云化测试工具提供性能测试、API 调试和监测 等多种能力紧密结合监控、流控等产品提供一站式高可用能力高效检验和管理业务性能。
3、Serverless 产品家族 FC函数计算是一个事件驱动的全托管 Serverless 计算服务用户无需管理服务器等基础设施 只需编写代码并上传函数计算会准备好计算资源并以弹性、可靠的方式运行业务代码。
SAEServerless 应用引擎实现了 Serverless 架构 微服务架构的完美融合真正按需使用、按量计费节省闲置计算资源同时免去 IaaS 运维有效提升开发运维效率SAE 支持 Spring Cloud、Dubbo 和 HSF 等流行的微服务架构。
Serverless 工作流是一个用来协调多个分布式任务执行的全托管 Serverless 云服务致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作让用户聚焦业务逻辑开发。用户可以用顺序、分支、并行等方式来编排分布式任务服务会按照设定好的顺序可靠地协调任务执行 跟踪每个任务的状态转换并在必要时执行用户定义的重试逻辑以确保工作流顺利完成。
4、Service Mesh产品家族
服务网格ASM提供全托管的微服务应用流量管理平台兼容 Istio 的同时支持多个 Kubernetes 集群中应用的统一流量管理为容器和虚拟机中应用服务提供一致的通信、安全和可观测能力。
AHAS应用高可用服务是专注于提高应用及业务高可用的工具平台目前主要提供应用架构探测感知故障注入式高可用能力评测和流控降级高可用防护三大核心能力通过各自的工具模块可以快 速低成本的在营销活动场景、业务核心场景全面提升业务稳定性和韧性。
5、消息产品家族
消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可 靠的分布式消息中间件。该产品最初由阿里巴巴自研并捐赠给 Apache 基金会服务于阿里集团 13 年 覆盖全集团所有业务支撑千万级并发、万亿级数据洪峰历年刷新全球最大的交易消息流转记录。
消息队列 Kafka 版是阿里云基于 Apache Kafka 构建的高吞吐量、高可扩展性的分布式消息队列服 务广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等是大数据生态中不可或缺 的产品之一阿里云提供全托管服务用户无需部署运维更专业、更可靠、更安全。
消息队列 AMQP 版由阿里云基于 AMQP 标准协议自研完全兼容 RabbitMQ 开源生态以及多语 言客户端打造分布式、高吞吐、低延迟、高可扩展的云消息服务。
微消息队列 MQTT 版是专为移动互联网 (MI)、物联网 (IoT) 领域设计的消息产品覆盖互动直播、 金融支付、智能餐饮、即时聊天、移动 Apps、智能设备、车联网等多种应用场景通过对 MQTT、 WebSocket 等协议的全面支持连接端和云之间的双向通信实现 C2C、C2B、B2C 等业务场景之 间的消息通信可支撑千万级设备与消息并发真正做到万物互联。
阿里云消息服务 MNS 是一种高效、可靠、安全、便捷、可弹性扩展的分布式消息服务 , 能够帮助应 用开发者在他们应用的分布式组件上自由的传递数据、通知消息构建松耦合系统。
事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务支持阿里云服务、自定义应用、 SaaS 应用以标准化、中心化的方式接入并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路 由事件帮助用户轻松构建松耦合、分布式的事件驱动架构。
6、数据库产品家族
PolarDB 是阿里巴巴自主研发的下一代关系型分布式云原生数据库目前兼容三种数据库引擎MySQL、PostgreSQL、高度兼容 Oracle 语法计算能力最高可扩展至 1000 核以上存储容量最高 消息产品家族 云原生数据库产品家族 6 7 The Cloud-native Architecture White Paper by Alibaba Cloud 50 可达 100T。PolarDB 经过阿里巴巴双十一活动的最佳实践让用户既享受到开源的灵活性与价格又享受到商业数据库的高性能和安全性。
PolarDB-X原 DRDS 升级版是由阿里巴巴自主研发的云原生分布式数据库融合分布式 SQL 引擎 DRDS 与分布式自研存储 X-DB专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算效率等数据库瓶颈难题历经各届天猫双 11 及阿里云各行业客户业务的考验助力企业加速完成业务数字化转型。
7、大数据产品家族
云原生数据仓库 AnalyticDB MySQL 版简称 ADB原分析型数据库 MySQL 版是一种支持 高并发低延时查询的新一代云原生数据仓库全面兼容 MySQL 协议以及 SQL:2003 语法标准可以对 海量数据进行即时的多维分析透视和业务探索快速构建企业云上数据仓库。产品规格按需可选基础 版成本最低适合 BI 查询应用集群版提供高并发数据实时写入和查询能力适用于高性能应用弹性 模式版本存储廉价按量计费适用于 10TB 以上数据上云场景。
云原生数据仓库 AnalyticDB PostgreSQL 版支持标准 SQL 2003兼容 PostgreSQL / Greenplum, 高度兼容 Oracle 语法生态具有存储计算分离在线弹性平滑扩容的特点既支持任意 维度在线分析探索也支持高性能离线数据处理是面向互联网金融证券保险银行数字政务 新零售等行业有竞争力的数据仓库方案。
云原生几个核心技术和未来发展趋势
1. 容器
容器作为标准化软件单元它将应用及其所有依赖项打包使应用不再受环境限制在不同计算环境间快速、可靠地运行。
随后开源的 Kubernetes凭借优秀的开放性、可扩展性以及活跃开发者社区在容器编排之战中脱颖而出成 为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性 帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境。企业可以通过 Kubernetes结合自身业务特 征来设计自身云架构从而更好支持多云 / 混合云免去被厂商锁定的顾虑。伴随着容器技术逐步标准化进一步促进了容器生态的分工和协同。基于 Kubernetes生态社区开始构建上层的业务抽象比如服务网格 Istio、机器学 习平台 Kubeflow、无服务器应用框架 Knative 等。
Kubernetes 已经成为容器编排的事实标准被广泛用于自动部署扩展和管理容器化应用。Kubernetes 提 供了分布式应用管理的核心能力
资源调度根据应用请求的资源量 CPU、Memory或者 GPU 等设备资源在集群中选择合适的节点来运 行应用
应用部署与管理支持应用的自动发布与应用的回滚以及与应用相关的配置的管理也可以自动化存储卷 的编排让存储卷与容器应用的生命周期相关联
自动修复Kubernetes 可以会监测这个集群中所有的宿主机当宿主机或者 OS 出现故障节点健康检查 会自动进行应用迁移K8s 也支持应用的自愈极大简化了运维管理的复杂性
服务发现与负载均衡通过 Service 资源出现各种应用服务结合 DNS 和多种负载均衡机制支持容器化 应用之间的相互通信
弹性伸缩K8s 可以监测业务上所承担的负载如果这个业务本身的 CPU 利用率过高或者响应时间过长 它可以对这个业务进行自动扩容。
Kubernetes 的控制平面包含四个主要的组件API Server、Controller、Scheduler 以及 etcd。如下图
2. 微服务
微服务四代架构演进
第一代
第一代微服务架构中应用除了需要实现业务逻辑之外还需要自行解决上下游寻址、通讯以及容错等问题。随着微服务规模扩大服务寻址逻辑的处理变得越来越复杂哪怕是同一编程语言的另一个应用上述微服务的基础能力都需要重新实现一遍。
第二代
第二代微服务架构中引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化形成独立服务框架。但是随着服务框架内功能日益增多用不同语言的基础功能复用显得十分困难这也就意味着微服务的开发者被迫被绑定在某种特定语言上从而违背了微服务的敏捷迭代原则。
第三代
2016 年出现了第三代微服务架构 - 服务网格原来被模块化到服务框架里的微服务基础能力被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决微服务基础 能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices边车Sidecar进程开始接管微服务应用之间的流量承载第二代中服务框架的功能包括服务发现、调用容错到丰富的服务治理功能例如权重路由、灰度路由、流量重放、服务伪装等。
第四代
近两年开始随着 AWS Lambda 的出现部分应用开始尝试利用 Serverless 来架构微服务这种方式被称之为第四代微服务架构。在这个架构中微服务进一步由一个应用简化为微逻辑Micrologic从而对边车模式提出了更高诉求更多可复用的分布式能力从应用中剥离被下沉到边车中例如状态管理、资源绑定、链路追踪、事务管理、安全等等。同时在开发侧开始提倡面向 localhost 编程的理念提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构Muti-Runtime Microservices。
OAM
2019 年末阿里云联合微软共同发布了 Open Application Model (OAM) 开源项目其主要目标是解决从 Kubernetes 项目到“以应用为中心”的平台之间最关键环节——标准化应用定义。
OAM 的第一个设计目标就是补充“应用”这一概念建立对应用和它所需的运维能力定义与描述的标准 规范。换而言之OAM 既是标准“应用定义”同时也是帮助封装、组织和管理 Kubernetes 中各种“运维能力”。
OAM 项目的第二个设计目标就是提供更高层级的应用层抽象和以应用关注点分离的定义模型。
相 比 于 传 统 PaaS 封 闭、 不 能 同“ 以 Operator 为 基 础 的 云 原 生 生 态” 衔 接 的 现 状 基 于 OAM 和 Kubernetes 构建的现代云原生应用管理平台的本质是一个“以应用为中心”的 Kubernetes保证应用平台能够无缝接入整个云原生生态。同时OAM 进一步屏蔽掉容器基础设施的复杂性和差异性为平台使用者带来低心智负担的、标准化的、一致化的应用管理与交付体验让一个应用描述可以完全不加修改的在云、边、端等任何环境下直接交付运行起来。
无状态服务Serverless
当 BaaS 云服务日趋完善时Serverless 因为屏蔽了服务器的各种运维复杂度让开发人员可以将 更多精力用于业务逻辑设计与实现而逐渐成为云原生主流技术之一。Serverless 计算包含以下特征
全托管的计算服务客户只需要编写代码构建应用无需关注同质化的、负担繁重的基于服务器等基础设施 的开发、运维、安全、高可用等工作
通用性结合云 BaaS API 的能力能够支撑云上所有重要类型的应用
自动的弹性伸缩让用户无需为资源使用提前进行容量规划
按量计费让企业使用成本得有效降低无需为闲置资源付费。
服务网格Service Mesh
Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术旨在将那些微服务间的连接、安全、流 量控制和可观测等通用功能下沉为平台基础设施实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相关治理问题而聚焦于业务逻辑本身提升应用开发效率并加速业务探索和创新。换句话说因为大量非功能 性从业务进程剥离到另外进程中Service Mesh 以无侵入的方式实现了应用轻量化。
Service Mesh的典型架构 Service A 调用 Service B 的所有请求都被其下的 Proxy在 Envoy 中是 Sidecar 截获 代理 Service A 完成到 Service B 的服务发现、熔断、限流等策略而这些策略的总控是在 Control Plane 上配置。
行业现状Service Mesh 目前在市场仍处于早期采用 (Early adoption) 阶段。除 Istio 以外Google 与 AWS 分别推出了各自的云服务 Traffic Director、 App Mesh。这两个 Service Mesh 产品与 Istio 虽有所不同但与 Istio 同样地采纳了 Envoy 作为数据平面。此外阿里云、腾讯云、华为云也 都推出了 Service Mesh 产品同样采用 Envoy 技术作为数据面并在此基础上提供了应用发布、流量管控、APM 等能力。 DevOps
DevOps 就是为了提高软件研发效率快速应对变化持续交付价值的的一系列理念和实践其基本思想就是 持续部署CD)让软件的构建、测试、发布能够更加快捷可靠以尽量缩短系统变更从提交到最后安全部署到生产 系统的时间。要实现持续部署CD)就必须对业务进行端到端分析把所有相关部门的操作统一考虑进行优化利用所可用的技术和方法用一种理念来整合资源。DevOps 理念从提出到现在已经深刻影响了软件开发过程。DevOps 提倡打破开发、测试和运维之间的壁垒利用技术手段实现各个软件开发环节的自动化甚至智能化被证实对提高软件生产质量、安全缩短软件发布周期等都有非常明显的促进作用也推动了 IT 技术的发展。
DevOps四大原则
文化Culture---要实施 DevOps就首先要让开发和运维人员认识到他们的目标是一致的只是工作岗位不同需要共担责任。这就是 DevOps 需要首先在文化层面解 决的问题。只有解决了认知问题才能打破不同团队之间的鸿沟实现流程自动化把大家的工作融合成一体。
自动化Automation---DevOps 的持续集成的目标就是小步快跑快速迭代频繁发布。实施 DevOps首先就要分析已有的软件开发流程尽量利用各种工具和平台实现开发和发布过程的自动化。经过多年发展业界已经有一套比较成熟的工具链可以参考和使用不过具体落地还需因地制宜。
度量Measurement---通过数据可以对每个活动和流程进行度量和分析找到工作中存在的瓶颈和漏洞以及对于危急情况的及时报警等。通过分析可以对团队工作和系统进行调整让效率改进形成闭环。度量首先要解决数据准确性、完整性和及时性问题其次要建立正确的分析指标。DevOps 过程考核的标准应该鼓励团队更加注重工具的建设自动化的加速和各个环节优化这样才能最大可能发挥度量的作用。
共享Sharing--- 要实现真正的协作还需要团队在知识层面达成一致。通过共享知识让团队共同进步可见度 visibility让每个人可以了解团队其它人的工作。这样可以知道是否某一项工作会影响另一部分。通过相互反馈让问题尽早暴露。透明性 transparency让每个人都明白工作的共同目标知道为什么要干什么。缺乏透明性就会导致工作安排失调。知识的传递 transfer of knowledge 知识的传递是为了解决两个问题一个是为了避免某个人成为单点从而导致一个人的休假或离职就导致工作不能完成。另一个是提高团队的集体能力团队的集体能力要高于个人的能力。
云原生未来发展趋势 趋势一无处不在的计算催生新一代容器实现
随着互联网的发展到万物智联5G、AIoT 等新技术的涌现随处可见的计算需求已经成为现实。针对不同计算场景容器运行时会有不同需求。KataContainer、Firecracker、gVisor、Unikernel 等新的容器运行时技术层出不穷分别解决安全隔离性、执行效率和通用性三个不同维度的要求。OCIOpen Container Initiative标准的出现使不同技术采用一致的方式进行容器生命周期管理进一步促进了容器引擎技术的持续创新。其中我们可以预见以下几个细分方向的未来趋势
基于 MicroVM 的安全容器占比将逐渐增加提供更强的安全隔离能力。虚拟化和容器技术的融合已成为未来重要趋势。在公共云上阿里云容器服务已经提供了对基于 KataContainer 的阿里云的袋鼠容器引擎支持可以运行不可信的工作负载实现安全的多租隔离。
基于软硬一体设计的机密计算容器开始展露头角。比如阿里云安全、系统软件、容器服务团队以及蚂蚁金服可信原生团队共同推出了面向机密计算场景的开源容器运行时技术栈 inclavare-containers 支持基于 Intel SGX 机密计算技术的机密容器实现如蚂蚁金服的 Occlum、开源社区的 Graphene 等 Libary OS。它极大降低了机密计算的技术门槛简化了可信应用的开发、交付和管理。
WebAssembly作为新一代可移植、轻量化、应用虚拟机在IoT边缘计算区块链等场景会有广泛的应用前景。WASM/WASI 将会成为一个跨平台容器实现技术。近期 Solo.io 推出的 WebAssembly Hub 就将 WASM 应用通过 OCI 镜像标准进行统一管理和分发从而更好地应用在 Istio 服务网格生态中。
趋势二云原生操作系统开始浮现
Kubernetes 已经成为云时代的操作系统。对比 Linux 与 Kubernetes 的概念模型他们都是定义了开放的、 标准化的访问接口向下封装资源向上支撑应用。 服务网格的技术发展上数据平面与控制平面间的协议标准化是必然趋势。大体上Service Mesh 的技术发展围 绕着“事实标准”去展开——共建各云厂商共同采纳的开源软件。从接口规范的角度Istio 采纳了 Envoy 所实现的 xDS 协议将该协议当作是数据平面和控制平面间的标准协议Microsoft 提出了 Service Mesh InterfaceSMI 致力于让数据平面和控制平面的标准化做更高层次的抽象以期为 Istio、Linkerd 等 Service Mesh 解决方案在服务观测、流量控制等方面实现最大程度的开源能力复用。UDPAUniversal Data Plane API是基于 xDS 协议而发展起来以便根据不同云厂商的特定需求便捷地进行扩展并由 xDS 去承载。
服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心 问题。随着云原生技术的发展服务发现领域出现了两个趋势一个是服务发现标准化Istio一个是服务下沉 (CoreDNS)配置管理领域也有两个趋势一个是标准化ConfigMap一个是安全 (Secret)。
趋势三Serverless 容器技术逐渐成为市场主流
Serverless 和 容 器 技 术 也 开 始 融 合 得 到 了 快 速 的 发 展。通 过 Serverless 容 器 一 方 面 根 本 性 解 决 Kubernetes 自身复杂性问题让用户无需受困于 Kubernetes 集群容量规划、安全维护、故障诊断等运维工作一方面进一步释放云计算能力将安全、可用性、可伸缩性等需求下沉到基础设施实现。
趋势四动态、混合、分布式的云环境将成为新常态
上云已是大势所趋但对于企业客户而言有些业务出于对数据主权、安全隐私的考量会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性和避免云厂商锁定等需求会选择多个云厂商。混合云 / 多云 架构已成为企业上云新常态。Gartner 指出 到 2021超过 75% 的大中型组织将采用多云或者混合 IT 战略。
阿里云容器服务 ACK 去年 9 月份发布了混合云 2.0 架构提供了完备的混合云 Kubernetes 管理能力。
零售云基于云原生体系建设和挑战
零售云是云原生应用实践的良好土壤
CTO 鲁肃提过阿里经济体是云原生技术发展的最好土壤。而零售云是阿里经济体重要的一个分支同时是阿里业务中台对外输出建设2B生态的重要战略方向所以零售云无疑是云原生应用发展实践的极好土壤。当前在这半年来实践和应用了云原生技术构建了产品-零售云研发运营平台即云上星环。
服务化能力商业能力API商业能力二次开发SDK 弹性能力站点PaaS部署发布规划建设中 自动化水平一键拉起环境一键部署平台应用 可观测性一键日志查询和监控运维
零售云基于云原生的技术架构 零售云基于云原生技术体系之上的分层架构
零售云DevOps实践
研发运营平台是零售云的重要的研发、监控和运维一体化平台为零售云业务系统研发提供完整的 DevOps 解决方案。
零售云基于云原生的接下来规划和挑战
个人观点我们需要基于阿里巴巴云原生架构设计方法论
一、组织视角
组织上需要从技术、业务和产品体系建设规划好阵型进行很好的排兵布阵需要更多的各领域的优秀人才加入建设建议组织上重点需要内部各领域专有人才定向培养内部同学有可持续发展通道才能留住人才、用好人才用人做事在零售云组织体系上尤其重要而不是做事用人否则项目就会把整个组织拖垮。
二、企业和业务视角
从 ISV 和客户视角去看零售云该怎么构建产品和快速交付而云原生技术体系将可以帮助快速构建 2B 生态的产品和技术体系。云原生技术体系基本可以使用阿里云的云产品和技术基础实施面对不能满足的场景需要考虑自建还是共建方式我的理解是零售云是业务和产品为导向的 2B 交付有很多个性化的诉求阿里云的云原生体系更多的是从通用角度考虑对于个性化和差异化需求零售云需要进行补充和扩展云原生技术/产品体系建设诸如商业能力客户侧部署发布不能依赖阿里云云效服务 SLA 的标准差异化等。
三、云原生技术架构视角
零售云当前已经基于阿里云 Kubernetes(ACK) 构建了零售云中台飞鹤版本零售云中台基线版本在建设中。面向明年20家客户交付后年 100 家客户交付我们需要构建通用的技术底座和产品基线以通用的技术底座和产品基线进行快速复制分支交付和版本管理满足独立部署交付和 SaaS 交付两种模式。当前构建独立部署交付模式务必需要考虑 SaaS 交付的产品和技术体系在适当时机需要开始 PaaS 平台的建设。
容器我们需要坚定的使用 KubernetesACK结合零售行业的特性Serverless 不是强需求 ASK 短期可以不用。容器建设上需要考虑多租户容器逻辑和物理隔离多租户容器运行时管理等。
微服务结合零售云现状我们采用了 Dubbo 框架建议可以走向微服务第三代架构加强 SideCar 的规划和建设诸如多租户数据隔离、权重路由、灰度路由、流量重放、服务伪装、流量打标、流量调度、计量管理、计费管理都将是需要重点建设方向可以架构设计上保证可扩展能力建设这些能力根据我们前方项目打仗来适度调整优先级。
OAM 方面可以结合阿里云的进展情况以及零售云近三年项目交付的场景来看是否需要引入我们的技术架构是可以支持可扩展这些基础能力的。
服务网格 ServiceMesh 跟微服务架构联系起来即 SideCar 的规划和建设(需要看看阿里云的 SideCar 是否满足零售云需求lstio 可以解决开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战部署交付是一个难点和挑战Istio 为可扩展性而设计可以满足不同的部署需求。
DevOps 是我们建设的一个重点研发平台、产品中心、支撑平台SideCar可以放在这里建设和站点 PaaS 以及通用的 PaaS 交付平台建设在中长期的意义非常关键这个产品体系当前还是初步规划阶段还需要验证和实践建议需要更全面和更深度的探索后进一步完善我们的产品体系避免产品的重复和来回废弃折腾建设。商业能力是零售云对外交付的输出产物商业能力建设和商业能力研发平台建设是重心。当零售云中台的开发和版本演进变成一个常规化的easy事商业能力对外交付变成快速可持续迭代的状态那么我们的产品建设就初成形态了。
低代码开发也是一个重要方向期望能够低成本交付以及客户低成本开发运维低代码开发是非常关键类似 Salesforce 的 Ligthnig 产品的建设我们需要从多维度去建设客户基于商业能力二次开发需要低代码开发 Maybe 基于元数据驱动建设零售云产品体系是好的选择这个方向需要探索和结合场景实践低代码开发需要根据场景选择产品有些场景适合使用纪元有些场景适合使用 Astore 有些场景适合使用类似斑马产品有些场景适合使用宜搭 Pro/ 宜搭我们需要有一个底座需要和云原生的技术体系结合然后更好更多的整合产品进来形成一个场景系列解决方案。低代码开发的思考我将在另外一篇文章中进行总结和思考。 原文链接 本文为阿里云原创内容未经允许不得转载。
