云原生
概述
参考:
Cloud Native(云原生)
我们来看看这些大牛们都如何定义云原生的:
- 2010 年,WSO2 技术总监 PaulFremantle 首次提出 Cloud Native,他一直想用一个词表达一个架构,这种架构能够描述应用程序和中间件能够在云环境中有良好的运行状态。云原生有以下特性 分布式、弹性、多租户,子服务,按需计量和计费,增量部署和测试。2013 年,Netflix 云架构师,Adrian Cockcroft 介绍了 Netflix 在 AWS 上基于 Cloud Native 的成功应用,Netflix 在 AWS 上有上万个实例。
- 2015 年,来自 Pivotal 的 Matt Stine,他的电子书《迁移到云原生应用架构》,他认为单体架构在向云原生架构的演进过程中,需要流程、文化、技术共同变革,该书把 Cloud Native 描述为一组最佳实践,具体包含如下内容:十二因子,微服务,敏捷基础设施,基于 API 的协作,反脆弱性。
- 2017 年,Matt Stine 在接受媒体采访时又改了口风,将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理 6 特质;而 Pivotal 最新官网对云原生概括为 4 个要点:DevOps+持续交付+微服务+容器。
- 2015 年云原生计算基金会(CNCF)成立,最初把云原生定义为包括:容器化封装+自动化管理+面向微服务。
- CNCF 于 2018 年通过了对云原生重新定义的提案,V1.0 的定义如下:
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
- 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生的发展历程
云原生的发展也可以理解为软件架构设计的 Modular(模块化) 演进
下面用一个常见的电商场景来说明:
最早的单体应用时代
所有功能都在一个程序里:
- 用户管理(注册、登录、个人信息)
- 商品管理(商品列表、详情、库存)
- 订单管理(下单、支付、订单查询)
- 购物车
- etc.
软件架构问题:
- 纵向扩容达到上限
- 随着使用量越来越多,程序占用的计算机的硬件资源越来越多,但是这台计算机本身的硬件资源已经达到极限,无法再向上扩容了
此时来到了分布式应用时代
分布式单体应用时代
当单一计算机无法增加硬件资源能力时,需要横向扩容,把 “增加 CPU, MEM, etc. 资源”,改为 “增加计算机的数量”,让多台计算机都部署电商程序,通过集群与分布式的方式提供电商服务。
分布式问题:
- 使用者认知负担加重
- 使用者如何知道我要访问哪台设备来购物?就算知道了,如何能让 N 个使用者平均选择 M 台计算机?
- Reverse Proxy(反向代理)来解决(e.g. Nginx)(Tips: 在后续的微服务时代,也成为了服务 Gateway(网关) 的雏形)
软件架构问题:
- 发布的影响范围较大
- 假如用户管理功能有 BUG,更新程序时,相当于所有功能一起更新
- 扩容能力有限
- 某次促销,有压力的功能只有订单管理功能,此时要横向扩容增加计算机,但是却变相浪费了非常多的资源,因为除了订单管理之外的其它功能并不需要扩容。
分布式服务时代
当产品逻辑越来越复杂,单体应用的弊端越来越多。我们需要把一个单体应用拆分为多个互相关联的服务,实现 Modular(模块化)。各种服务可以交互部署在整个服务器集群之上
软件架构问题:
- 配置管理困难
- 各个服务都要维护需要交互的其他服务的 IP:PORT, etc. 信息。任何一个服务的迁移(需要更多资源扩容、计算机宕机、etc.)都需要让所有服务同步更新配置
- 状态感知困难
- 若某个服务集群的其中一个节点故障,其他服务若无法及时感知,依然会把请求发送给故障服务,导致整个业务出现问题。
- 统一认证、限流等功能遇到挑战
- 这么多服务,如果每个服务都需要添加独立的认证、限流功能,造成代码编写困难,故障点增多
微服务时代
为了解决应用模块后产生的各种问题,引出了两种概念
- ServiceDiscovery(服务发现) # 服务发现程序用来接受所有服务注册过来的信息,并持续验证其是否可用
- Gateway(网关) # 通常指 API 网关。实现各服务的通用功能,e.g. 认证、限流、etc. 。实现了常见反向代理(e.g. Nginx)的部分功能,可以对接服务发现中心,动态得更新后端设备信息。
微服务与无服务
Knative
参考:
反馈
此页是否对你有帮助?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.