大家都知道我们的服务架构经历了单体架构–集群架构–微服务架构的演进。我们的程序架构经历了MVC–RPC–SOA–微服务架构的演进。
而在架构演进的过程中，我们越来越多地使用到各种开源产品。
在我的理解中，云原生是一种最佳理念的集合，前提是上云。
比如我单体架构使用了云产品redis，而这种中间件就是最适合我产品需求的，那我就可以说，我的单体架构融入且符合了云原生概念。
也有说法是，服务上云才就是原生，这个说法我是不太赞同的。
云服务很多都是比较好的中间件或是应用服务，我们使用了这些云服务能更优化我的产品，这就是符合了云原生的概念，如服务治理。但是，如果我们的服务是很小的单实例服务，使用本地部署和维护都很方便，那上云的意义就并不大了，也不符合云原生最佳实践的理念，上云只是为了减小我们的维护和运营成本。
再聊到低代码，这个国内部分人正在研究的一个课题，但是在国外已经很流行了，而且这种低代码也主要是为国外的习惯和行情而研发的。
它会先写各种工具类，让大家以后都使用好的工具类，而不需要去关注底层的代码实现。
或者是它会先完成很多模块的开发，让其他服务直接调用这种模块，也是不关心底层的实现逻辑，能大大提高开发进度。
但凡事有利有弊，当未来的开发者习惯了使用这种方式，而忽略了一些好的底层实现逻辑，那未来我们的技术就缺乏了创新的土壤。低代码只能是解决我们的一时之需。
国外有这种需求我觉得偏向他们的开发人员数量在下降，而国内的开发者越来越多，我觉得还是要从底层学起，让专家们多分享好的底层设计思路，多讨论更符合多样化环境下的架构设计，在节约成本的基础上，还能让技术得到提升，这样国内的技术水平才能越来越好
所以个人观点是，支持复杂环境的云原生化，不支持无脑的低代码化。不知道你是怎么理解的，可以留下你的观点，欢迎来喷。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。