从资源上云到架构上云：云原生实践初体验

几个月前发过一篇文章讨论技术思路，接着上次的讨论继续。

在之前的阶段，有几个问题一直悬在我的头顶没办法解决，这些问题促成了上周开始的架构迁移。

首先是前后端不分离的问题。前后端不分离的缺点是，无法用前端的工具链去解决前端问题，而只能用类似于Django模板语言等上一代方案。Django模板语言写静态网页问题不太大，稍微复杂一些就体现了非常多的缺点，自定义模板标签也解决不了问题；后端架构为了同时兼容HTML和JSON格式的访问请求，也需要做很多处理。很快Web端的开发就走上了死路。但之所以不做前后端分离，主要还是因为多一套框架就多一套运维成本，项目变大以后这也会形成灾难后果。

然后是Django为代表的重后端和以小程序云开发为代表的重前端的打架。小程序云开发上线以来我就一直在关注，我十分喜欢这种开箱即用的开发模式，也非常符合我对于前后端运维一体化的需求。但一直以来，我非常头疼的是，两套技术架构似乎看起来井水不犯河水，我没有办法把后端的能力用在云开发，也没有好的办法把前端的项目放在Django里一起托管。

（PS：那阵子后来生病了，就没有继续参加比赛。）

最大的问题是，随着对项目规划的深入，我发现很多模块开始变的越来越不必要的复杂。我原本不想在早期就中台上花过多时间，但不去解决这些技术问题，就会给后续的开发留下非常多的包袱。这样，项目规模就不可避免地越来越大，以至于到了不知道怎么进行下去的地步。

以上的这些问题，困扰了我两三个月，让我非常痛苦。

非常巧的是，上个月月底去北京参加了小程序云开发的发布会，我的以上所有问题都得到了初步的解决。

原本我去参会只是去听一下我感兴趣的技术领域，带我的新成员去开会感受一下技术氛围，并没有打算获得什么。会议结束以后，我参加了和云开发团队交流的闭门会，和他们近距离的讨论了很多技术想法以后，发现我想要的东西已经有了解决方案，这个东西在腾讯云云开发叫做“云托管”（CloudBase Run）。虽然我对它的可用性存疑，不过在云开发团队的总经理和工程师们的鼓动下，我还是打算试试。这一试，发现果然是我一直以来想搞的东西。

首先是前后端一体化运维的问题。云开发是以“环境”为单位管理资源的。在一个环境下，可以有Serverless服务，有云函数，有数据库，有存储，有静态托管，有HTTP代理等等。因此，我只需要把所有的前后端项目统一放到一个云开发的“环境”下，就可以完美解决我的困惑。

然后是两套技术方案的融合。CloudBase Run这个PasS服务的定位，正好就是用自建的Web服务代替云函数来提供服务。这样，CloudBase Run可以作为云开发的Web服务提供给小程序，从而成功让两套技术方案融合。

中台的需求随着云原生框架的引入，也变的简单很多。云开发有登录鉴权功能，这样用户中台的定位从一个需要做大量鉴权工作的业务中台，变成了一个主要处理用户数据、为商业策略提供决策支持的数据中台。由于云开发自带了日志管理，原本计划的日志中台也轻了很多。随着容器的引入，原本繁琐的部署工作变的标准化和简单化。

在云开发体系下，开发效率也得到了很大提高。云托管本质上作为一个k8s平台，为开发者做了大量的自动化工作，让自动构建和自动部署变的比较简单；再结合Coding的CI、CD能力以后，就可以完成全自动化了。云托管以“服务”和“版本”为单位，以“服务”这个单位，开发者可以轻松地部署一个微服务到同一个“环境”里，让这个项目对外看起来依然像一个整体，登录鉴权、HTTP代理这些功能都可以复用。这样内部团队就可以轻松地根据服务来拆分团队和个人的任务，项目会容易维护地多。以“版本”为单位，则很好地解决了灰度发布和蓝绿发布的问题。这些为持续交付提供了很好的工具，以及对于AB测试的原生支持让数据科学家们有了更方便的工具做业务逻辑测试。

目前的云开发（CloudBase）还存在非常多的缺陷，不过依然表现了很大的潜力。我上周三开始迁移，到今天是第六天，已经基本上迁移2/3了，同时还把Coding和CI、CD流程搭了起来。这其中大部分的时间是在解决云开发的一些没有完善的技术问题。对于有一定规模的未上线项目或者规模较小的已上线项目，云开发和云托管体现了非常顺畅的托管能力，这些缺点被理顺以后，云托管会成为中小企业和大公司的创新业务的福音。在这篇文章里，我就不去具体分析缺点了，后续的文章会专门讨论，也会在具体项目中讨论解决方案，届时我会用机构号@量潮科技 发布我们自己的解决方案和团队层面对云原生的思考。

最后，非常感谢云开发的工程师们加班陪着我改BUG，为我们提供了非常多的帮助！