目录
文章目录
云原生应用的特征
- 普遍可访问（Universal Availability） ：服务可在任何地方从多前端访问。
- 高可用性（High Availability） ：基本服务随时在线。升级扩容服务无中断。单点失败影响范围小。失败触发自动恢复。负载均衡，自动限流降级熔断，异常流量自动调度，故障隔离，宕机自动迁移等。
- 高扩展性（Scalability） ：服务可以随业务需要随时迅捷线性伸缩。
- 自动弹性伸缩（Elasticity） ：服务可以随业务需要按定义自动伸缩。根据业务负载自动伸缩，做到秒级扩缩容能力，灵活动态分配或释放资源，结合弹性计费策略，这是降低用户费用重要手段之一，对服务而言需要的关键技术点就是服务本身的 “轻量级容器化” 和以此为基础的 “不可变基础设施” 特征。
- 可观测性（Observability） ：可以通过运维工具实时收集健康信息。丰富且细粒度的监控（实时指标、链路追踪、日志），秒级监控能力，做到自动化报警，可持久化的提供查询。
- 安全性（Security） ：高度安全，可抵御常规威胁。
- 可迁移性（Deployable to Different Cloud Suppliers） ：基础设施分离。易于迁移到不同的云计算供应商。
- 快速迭代（Fast Iteration） ：服务更新快速频繁。创新速度提高。为应对频繁变更带来的稳定性风险，需建立无人值守的变更发布系统，具备自动化的灰度、蓝绿等发布策略，同时建立变更前中后的监控基线，具备异常变更的熔断和自动化回滚能力。
- 演进式设计（Evolutionary Design） ：持续改进。
- 易于管理：需要从人工运维到自动运维的转变，具备自动化异常分析诊断能力，无需登录服务器。
- 弹性计费：支持按量（如流量，存储量，调用次数，时长等），按天（固定的如年/月/日），预留式，抢占式等多种定价策略，业务可根据实际情况灵活动态切换匹配出一个最优计量模式。
云原生应用的架构
- 云化微服务架构（Micro Service Architecture） ：性能专注，系统组成部件高度解耦。独立开发,快速部署，仿真测试，实时运维，资源独立。系统组件化。组件独立化。
- 基于云基础设施和服务（Based on Cloud Infrastructure and Services） ：通过按需自获取或释放的云基础设施（计算，网络，存储）和服务。
- 分布式云化部署（Distributed Deployment） ：服务部署在分布式的云基础设施上。快捷全球上线。
- 无状态（Stateless） ：请求可以由任何服务器处理。单点失败对服务功能无影响。
- 无本地依赖（Localless） ：依赖其它云资源，比如云存储（CloudData Service），云计算资源，基于云的缓存，消息队列等等云服务。
- 可水平扩展（Horizontal Scalable） ：应用性能可以随调整通用性服务器数量得到线性调整。
- 冗余性（Fault Tolerance） ：利用多点部署，负载均衡（ELB）。单节点失败对服务无影响。
- 服务注册与发现（Service Registration and Discovery）
- 自动弹性伸缩（Auto Scaling） ：服务可以随业务需要按定义自动伸缩。
- 去中心化（Decentralization） ：开放分布式系统。独立数据存储。
如何构建云原生应用
- 为了解决单体架构 “复杂度问题”，使用微服务架构。
- 为了解决微服务间 “通讯异常问题”，使用治理框架 + 监控。
- 为了解决微服务架构下大量应用 “部署问题”，使用容器。
- 为了解决容器的 “编排和调度问题”，使用 Kubernetes。
- 为了解决微服务框架的 “侵入性问题”，使用 Service Mesh。
- 为了让 Service Mesh 有 “更好的底层支撑”，将 Service Mesh 运行在 k8s 上。
从单个微服务应用的角度看，自身的复杂度降低了，在 “强大底层系统” 支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现 “强大底层系统” 付出的成本是非常昂贵（很强的架构和运维能力）的。
另外，企业为了实现这些功能所使用的技术栈及中间件体系是封闭的，私有化严重，很难满足所有的业务需求（包括阿里也存在这种情况）。“为了解决项目整体复杂度，选择上云托管”，将底层系统的复杂度交给云厂商，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 或 JSON 声明式代码，编排底层基础设施，中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的 “Cloud” 技术体系。
