云原生架构七大原则

  • 服务化原则
    • 当项目规模较大时需要进行服务化拆分，如微服务或小服务架构。服务化可以提高复用性，并方便对服务进行流量控制和治理。
  • 弹性原则
    • 系统应具备自动伸缩的能力，根据业务需求弹性整理资源。可以缩短上线时间、降低成本，并对应突发的业务扩张需求
  • 可观测性原则
    • 在分布式环境下需要更强的可观测性，包括日志、链路跟踪、指标等可以帮助运行、开发和业务人员实时掌握系统运行状态并进行优化
  • 韧性原则
    • 系统需要具备抵御各种硬件和软件异常的能力，提升平均无故障时间包括异步化、限流、降级、高可用等多维度的架构设计全流程自动化原则。
  • 全流程自动化原则
    • 利用自动化工具实现交付流程的标准化和自动化提高交付效率，并减少人工操作带来的风险。
  • 零信任原则
    • 不再依赖网络边界的安全思路，转向基于身份的访问控制。解决研发、测试、运维等场景下的隔离和访问控制问题。
  • 持续演进原则
    • 构架需具备持续演进的能力，应对技术和业务的快速变化。需要考虑遗留应用的迁移成本和风险，采取渐进式的架构演进策略

主要架构模式

  • 服务化架构模式
    • 典型模式是微服务和小服务模式。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的示例，单独扩缩容，从而使得整体的部署更经济。
  • Mesh化架构模式
    • 把中间件框架（RPC、缓存、异步消息等）从业务进行中分离，让中间件和SDK与业务代码进一步解耦。从而使得中间件升级对业务进程对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后的业务进行中只保留很“薄”的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全逻辑等基础逻辑由Mesh进程完成。
  • Serverless模式
    • 将“部署”这个动作从运维中“收走”，使开发者不需要关心应用运行地点、操作系统、网络配置、CPU性能等，从架构抽象来看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云会自动关闭/调度业务进程，等下一次触发，也就是把应用整个都委托给云。
  • 存储计算分离模式
    • 在云环境中，推荐把各类暂态数据（如session）、结构化和非结构化持久数据都采用云服务进来保存，从而实现存储计算分离。
  • 分布式事务模式
    • 大颗粒度的业务需要访问多个微服务，必然带来分布式事务的问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。
  • 可观测架构
    • 可观测架构包括Logging、Tracing、Metrics 三个方面。其中Logging提供多个级别的详细日志信息跟踪，由应用开发者主动提供；Tracing提供一个请求从前端到后端的完整的调用链路跟踪，对于分布式场景尤其有用；Metrics（指标）提供对系统量化的多维度度量指标。
  • 事件驱动架构
    • 本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景。