# 平台架构
# 概述
利用云原生技术，专注用户价值，秉持开放中立的理念，集成各种能力，面向组织用户提供统一应用界面。组织租户既可以获取应用也可以上架应用。上架应用应以组织为颗粒度设计多租户，用户从属于组织，组织有内设机构和岗位，用户可以加入多组织，组织之间可以组成集团。 区别于传统SaaS应用提供服务，组织或用户需要登陆服务地址，注册账号，提供相关用户认证信息。平台要求面向组织和用户聚合服务，SaaS应用必须注册到平台，组织用户登陆平台，即可获取、分配和使用SaaS服务。
# 设计理念
以组织用户为中心，利用云原生技术提升应用和数据的管理能力，让组织更专注核心业务的代码和数据，以All-in-one方式降低组织中用户对工作的心智负担。保持平台开放和中立，通过更细颗粒度的划分服务边界，明晰权责利关系，激发市场创新活力。充分释放云计算的技术红利，快速迭代，精益求精，为组织用户业务数字化改革和价值创造提供持续的推动力。
# 平台目标
成为面向组织用户的云原生操作系统。为组织用户提供统一操作界面，集中管理组织架构和用户体系，满足组织用户统一管理软件、业务数据和云资源等核心数字资产的需求，面向用户聚合各类云服务。利用云原生技术架构原则和设计模式，发挥平台优势，解开组织、应用、数据和资源的耦合关系，以应用市场上架和获取云服务方式，转变传统软件交付和分发模式，聚焦组织用户的核心价值，培育云服务市场生态，改进组织间大规模协作机制，优化信息资源配置，推动数字化改革，提高社会整体运转效率。
# 架构原则
# 服务化原则
合理的服务化拆分，包括微服务架构、小服务（Mini Service）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
# 弹性原则
系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。
# 可观测原则
主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等，可以实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。
# 韧性原则
是指当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，持续提供业务服务的能力。
# 自动化原则
通过 IaC、GitOps、OAM、Kubernetes operator 和大量自动化交付工具，CI/CD 流水线标准化软件交付过程，以配置数据自描述和面向终态的交付方式，让自动化工具隔离交付目标和环境差异，实现整个软件交付和运维的自动化。
# 零信任原则
默认情况下不应该信任网络内部和外部的任何人 / 设备 / 系统，需要基于认证和授权重构访问控制的信任基础，诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。以身份为中心进行访问控制。
# 架构持续演进原则
云原生架构本身是一个具备持续演进能力的架构，而不是一个封闭式架构。需要考虑在业务高速迭代情况下的架构、业务等各方面的平衡关系。动态、混合、分布式的云环境将成为新常态。统一技术栈，统一应用界面，统一管理界面，将公共云服务能力将延伸到边缘计算和IDC，云原生架构推进无边界云计算，促成云边端应用一体协调。云平台提供者负责服务的运维、治理、更新和演变。
# 架构模式
# 微服务架构
服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接 口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服 务化架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。
# Mesh 化架构
Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件 也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与Mesh 进程通讯，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。实施 Mesh 化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓……）都由Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。
# Serverless架构
利用 Serverless 来架构微服务。微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、基础设施的差异，进一步降低微服务开发难度。
# 推荐技术
全栈领域的 Serverless，使用 Kubernetes 等容器编排系统实现资源的伸缩和容错，自行搭建或集成监控报警系统。用户只需要专注于任务处理逻辑的处理，利用Serverless 计算的极致弹性可以很好地满足突发任务下对算力的需求。通过将对象存储和 Serverless 计算平台集成的方式，能实时响应对象创建、删除等操作，实现以对象存储为中心的大规模数据处理。用户既可以通过增量处理对象存储上的新增数据，也可以创建大量函数实例来并行处理存量数据。
典型 Serverless 计算服务通过事件驱动的方式，可以广泛地与云端各种类型服务集成，用户无需管理服务器等基础设施和编写集成多个服务的“胶水”代码，就能够轻松构建松耦合、基于分布式事件驱动架构的应用。通过和事件总线的集成，无论是一方 BaaS 云服务，还是三方的 SaaS 服务，或者是用户自建的系统，所有事件都可以快速便捷地被函数计算处理。例如通过和 API 网关集成，外部请求可以转化为事件，从而触发后端函数处理。通过和消息中间件的事件集成，用户能快速实现对海量消息的处理。
通过定时触发器，用户用函数的方式就能够快速实现定时任务，而无须管理执行任务的底层服务器。通过将定时触发器和监控系统的时间触发器集成，用户可以及时接收机器重启、宕机、扩容等 IaaS 层服务的运维事件，并自动触发函数执行处理。