云原生架构实践真正的诉求点-做好三个关键分离和解耦

图片

今天我接着跟大家聊一下云原生方面的一个内容，如果经常看我的文章或视频，你会发现在前面对于微服务，对于DevOps，对于云原生架构实践，我都谈过相当多的内容。我最近也在复盘我们自己相关的技术平台的研发，微服务的实践，包括云原生的一些实践，我自己也在不断的思考，我们真正的去实践云原生的时候，从我们的业务目标和业务场景出发，我们真正的诉求点究竟在哪里？

说实话我们做了这么多年的云原生和微服务架构的实践，很多东西仍然离我个人希望达到的一种理想化的状态还差距甚远。那么从业务诉求上面，对于云原生架构实践，我个人的理解它包括了三个关键的诉求点。下面稍微展开进行下说明。

1.业务和技术分离

第一个点就是我们是希望业务的开发和技术的开发能够逐渐的分离，我们希望我们的开发人员当面对大的一个业务场景业务需求的时候，它能够100%的将重心放在业务功能的实现上面，而不需要去关心你本身的底层的技术平台、技术架构，各种消息安全缓存等技术服务能力的提供。

大家都知道你要搭建一个底层的具备高可用高扩展的一个技术组件服务，这个本身也是具备相当大的难度的。比如说你要搭建底层的一个高可用的Redis集群，我们经常都在谈，它必须要是3+3六个节点才能完成这个事情。

所以说一般的开发人员，你让他完全具备搭建底层技术架构的能力相当困难。正是由于相当困难，我们希望开发人员能够将重心放在你的业务需求、业务功能、业务逻辑的实现上面，而不要去关心底层的技术平台，这是第一个分离。

2.开发和治理分离

第二个分离，我在前面一直在讲，我们希望达到功能的开发和后续的治理运维两件事情的分离。开发人员开发功能应该是相当纯粹的，它的重心业务流程的实现，业务功能的实现，业务规则和逻辑的实现，它所有的代码都是应该为业务功能实现服务的。

在开发的过程中，他不应该太多的去关心相关的你后续治理后续运维的事情。比如说我经常谈到的，我在开发过程中还要写大量的代码，这些代码是为了后面监控运维方便，是为了后续微服务治理管控方便，这些都是不合适的。

开发人员的重心就应该是在开发功能代码上面，而我刚才谈到的微服务治理，后续的可观测性，后续的微服务运维这些能力，它应该是自然而然能够自动的附加上我我们的微服务应用的，这个是我强调的第二个关键点。

3.开发和过程分离

第三个关键点我希望达到的是什么呢？

我们的功能开发或者是产品的研发，能够和我们的整个产品的集成和交付过程分离。开发人员只要把这个功能开发好，自己做好相当相关的功能模块的自测，后续整个功能模块怎么样去做集成，怎么样去做编译构建，怎么样从开发环境转到测试环境，怎么样从测试环境进一步交付发布到我们的生产环境，相应的持续集成和持续交付的过程最好都能够实现自动化，最好这些东西都不要让开发人员去关心。功能的开发应该和功能的交付的复杂过程，进一步的解耦和分离。

图片

以上三点就是我经常会谈到的，我们在去做云原生架构实践的时候，希望达到大的三个分离点。

• 业务技术分离->ServerLess无服务器化
• 开发治理分离->ServiceMesh服务网格
• 开发过程分离->DevOps最佳实践

第一个点，业务开发和技术的开发技术平台能力的分离，刚好对应了云原生中我们说的ServerLess无服务器化的最佳实践。第二个点功能的开发和功能的治理运维进一步去结合和分离，刚好对应了我们的ServiceMesh服务网格的最佳实践。第三个点产品功能的开发和产品的持续集成和交付的过程分离，刚好对应了我们的DevOps过程管理实践。这三个点刚好也是我在讲云原生最佳实践的时候经常谈到的希望达到的点。

如果你做好这三个点，我们讲你在实践云原生实践微服务的时候，往往就进入一种比较理想化的状态，这个也是我们在推行云原生推行微服务的时候，希望达到的一个最佳实践或者是最佳效果。

当然我们自己团队的实践离这个仍然都还有差距，我们仍然也是在不断的朝着理想化的目标去迈进。以上就是今天我想分享的一个关于云原生实践的方面的一个内容，希望对大家有所启发，再见。