既然我们已经知道什么是云原生架构，那么在落地实践过程中，我们应该怎样设计云原生架构呢？实际上云原生架构设计也是需要遵守一定设计原则的，这样才能确保实际落地的时候不会出现大的方向性的偏差。

服务化原则

不同的业务域对应不同的业务范围，这个时候就需要进行服务化拆分，将一个超大的单体平台按照业务域拆分为多个微服务，这样做的目的就是为了实现业务的分而治之，实现服务之间的部署解耦，各个业务域的微服务可以根据自身的节奏进行迭代，不必受制于其他服务。另外迭代发布变更的力度更小了，有利于整个产品平台稳定性的维护。另外拆分之后各个服务之间通过接口进行交互，使得微服务本身更加高内聚低耦合，同时在各个团队服负责的微服务之间没如果发现有些功能是大家都可以用到的，可以进行进一步的抽象沉淀形成公用木块，提升服务之间的复用度。

弹性伸缩原则

如何高效的利用服务器资源一直是企业级IT架构重点需要解决的问题，因为这涉及到服务运营成本问题，同样的服务但是的你的整体运营成本更低的话在市场上的竞争力肯定就会更强。传统的软件平台部署方式都是根据业务规模进行提前估算，确定业务应用、中间件以及负载代理等总共会占用多少服务器资源，资源到位后进行部署调试，这种软件平台部署方式耗时耗力，这种方式存在两个明显弊端。一个是当业务不繁忙的时候各个服务器的安全水位可能比较低，但是还是那么多服务器被占用，整体的资源使用率比较低，实际上是一种资源的浪费。另外一点在业务繁忙的时候不能及时的进行扩容，可能导致服务在大流量的时候被打垮，非常影响用户的业务体验。

可观测原则

相比于单机服务器时代，分布式环境下的问题定位以及平台运行状况对应的复杂度呈几何倍数增加。而在云原生的时代，服务都是运行在一个一个Pod当中，需要。因此无论是运维同学、开发同学还是运营同学，如果可以实时掌握整个平台的运行状况、各个业务业务链路的健康状态以及多维度的自下而上的指标数据，那么对于进一步实现业务分析以及业务数据运营都有着非常重要的意义。因此云原生架构应该是具备可观测能力的架构，可以通过技术手段获取各个节点的网络响应情况、慢SQL、服务调用链路以及接口耗时等等平台运行数据。

谁能实现更加敏捷的业务迭代，谁能最大程度的降低服务运营成本、谁能实现开发运维一体化，谁就能在未来激烈的市场中占有一席之地。越来越多的IT从业者以及领导者逐渐认识到“云原生化将成为企业技术创新的关键要素，也是完成企业数字化转型的最短路径”。因此作为从业者要具备前瞻眼光，逐渐拥抱云原生技术，把云原生架构作为企业下一代IT架构的演进方向，从而深度使用云原生技术与云原生架构，解决交付周期长、资源利用率低等实际业务问题。