Cloud Native 架构的组成

Cloud Native 是以云和微服务架构为基础构建系统，这里云可以是公有云、私有云、混合云等等。

架构演进：快速迭代、小步快跑

敏捷基础设施和公共基础服务

• 通过监控快速定位故障；
• 通过工具自动化部署、管理服务；
• 通过服务化框架降低服务开发的复杂度；
• 通过灰度发布提升可用性；
• 通过资源调度服务快速申请、释放资源；
• 通过弹性伸缩快速扩展应用；

微服务设计原则

• 垂直划分优先原则（根据业务领域对服务进行垂直划分）；
• 持续演进原则（逐步划分、持续演进，避免服务数量的爆炸性增长）；
• 服务自治、接口隔离原则（通过标准的接口隔离，隐藏内部实现细节）
• 自动化驱动原则（CI/CD）
• 无状态（Statelessness，将服务的状态外置到数据库、分布式缓存中，是服务变成无状态）

基础设施即代码

可通过编程的方式管理虚拟机或容器，免去手动配置、更新各个硬件，这样，使得基础设施具有弹性，能够快速、高效、准确地进行重复性操作。

研发流程

倡导敏捷文化、快速迭代，做更多的自动化测试，加强Code Review，给团队更多的自主决策权。

微服务拆分方式

1. 先拆分业务代码，在拆分数据。

2. 业务代码和数据库同步拆分。

第一种架构模式通常会被认为是微服务架构下的反范式（Anti Pattern），它的问题在于：

• 单点故障：一个数据库倒下，整批服务全部停止。何来的服务独立性？
• 数据在同一个地方，会给贪图方便的开发或者 DBA 工程师编写很多数据间高度依赖的代码；

第二种架构模式的问题是：需要做大量的数据迁移。相对来说，业务代码拆分成本更低。

建议做法，把第一种方式作为过渡阶段，当业务逐步稳定后，再彻底进行数据迁移。

微服务API 设计原则

• 简单易懂（正常思维逻辑，可读性等等）；
• 一致（ 统一的规则）；
• 稳定（1. 如果修改API无法避免，增加接口而不是修改已有的接口做兼容；2. 如果一定要改变已有的接口，通过明确的版本号加以区分）；
• 安全（限流）；
• 认证（如果提供给第三方，则要考虑认证，租户之间隔离等等）；