#yyds干货盘点#云原生的六条设计原则

#yyds干货盘点#云原生的六条设计原则

云原生是面向“云”而设计的应用，但要给云原生下一个明确的定义很难，所有的架构的目标都是解决特定的业务场景。那么在云原生落地的时候可以遵循哪些原则，才能更好地服务于业务发展。

1. 去中心原则

中心化意味着单点，为了具备良好的线性扩展能力，分布式系统要求去中心化，避免单点故障。微服务架构虽然也有一个服务注册中心，但服务注册中心只负责应用启动或者状态变更时做服务推送，真正在运行过程中微服务之间的相互调用都是点对点直接调用，即运行时是去中心化的。

云原生对开发团队一个很重要的要求是独立自主，每个服务由独立的团队负责开发运维，所有者的团队对服务具有决策权，可以自主选择技术栈以及研发进度，服务之间只要接口不变，外部就不必对其过度关注，更容易实现关注点分离。

2. 松耦合原则

服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响消费端，而且消费端未来还可以自由切换到该契约的其他服务提供方。其中包括时间的耦合、位置的耦合、版本的耦合等等。

3. 高可用原则

所有的外部调用都有容错处理，我们希望失败的结果是我们可预期的、经过设计的。在微服务架构场景中，当服务数量越来越多，依赖越来越复杂时，出现问题的概率也就越大，问题定位也会越来越困难，这时再用传统的解决办法将是一个灾难。

应充分考虑异常情况，从使用者的角度出发，能够容忍故障的发生，最小化故障的影响范围。系统架构设计时需要考虑到应用系统的每一个层面，包括硬件和软件是可能出现故障的，并据此在应用系统架构设计上消除单一故障点。

4. 无状态原则

服务在处理请求时，不依赖除请求本身以外的其他内容，也不会有除响应请求之外的额外操作。这样如果要实现无状态服务的并行横向扩展，只需要对服务节点进行并行扩展，在服务之上添加一个负载均衡。

云原生的应用服务设计尽可能是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容、缩容，满足业务需求。

5. 不变性原则

基础设施中的每个服务、组件都可以自动安装、部署，不需要人工干预。所有的资源都可以随时拉起、随时释放，同时以API的方式提供弹性、按需的计算、存储能力。每个服务或者组件在安装部署完成后将不会发生更改，如果要更改，就丢弃老的服务或组件，并重新部署一个服务或组件。另外，为了提升可用性，我们应该尽量减少故障修复时间，要知道替换的速度远远快于修复的速度。

6. 自动化原则

自动化驱动分为持续集成、持续部署、持续交付等阶段，用来确保需求的提出、设计开发测试，再到代码快速、安全地部署到生产环境中。

当提交代码后，自动化的工具链自动编译、构建、测试、集成。开发人员持续优化代码，当满足上线要求时，自动化部署到生产环境中。这种自动化的方式能够实现更可靠的操作，既避免了人为失误，又避免了微服务数量增多带来的开发、运维、管理的复杂化。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。