云原生架构
- 云原生架构是基于云原生技术的一组架构原则和设计模式的集合，
云原生架构原则
云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。
- 服务化原则: 当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务 (Miniservice)架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。
弹性原则: 大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商治谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期;而这期间如果业务发生变化了，重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出(闲置成本),降低了企业的 IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而“说不”,保障了企业收益。
可观测原则: 通过日志、链路跟踪和度量等手段，使得依次点击背后的多次服务
韧性原则：当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
所有过程自动化原则：一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
零信任原则: 默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心。
架构持续演进原则：云架构本身也必须是一个具备持续演进能力的架构。
主要架构模式
- 服务化架构模式
- Mesh 化架构模式
- Servicless 模式: 将“部署”这个动作从运维中“收走”,使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
- 存储计算分离模式:。在云环境中，推荐把各类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。
- 分布式事务模式:大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务式。
- 可观测架构:可观测架构包括Logging、Tracing、Metrics 三个方面，其中Logging 提供多个级别的详细信息跟踪，由应用开发者主动提供:Tracing 提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用:Metrics则提供对系统量化的多维度度量。
- 事件驱动架构:本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景中
云原生相关技术
- 容器技术
- 云原生微服务
- 无服务技术
- 服务网络