云原生应用云平台

　　一、微服务不微是因为什么

　　微服务不微，是很多人的困惑。

　　虽然有了全职能微团队（2张披萨饼）、微UI（移动APP和小程序技术）、微项目（每两周迭代发布一次），但微服务仍然不微。

　　虽然有了满足海量用户高并发的SpringCloud分布式微服务中间件、有了满足分布式部署和运维的DevOps（Jakins/Docker/k8s），但微服务仍然不微。

　　问题到底出哪里了？

　　咱们从开发流程再捋一捋。

　　软件公司嘛，软件代码是我们的核心资产。所以我们肯定有我们私有的Git源代码库，部署在我们公司的IDC机房里面，而且做层层的安全防护以及代码备份机制。

　　我们要开发的时候，需要在我们本地安装部署需要的各种框架，才能做本地开发、本地调试。但是现在为了应对高并发分布式中间件、海量大数据存储与计算、人工智能训练、物联网接入，我们需要安装的依赖的技术框架高达40多种以上。光部署调正常这堆框架已经把我们累的精疲力尽，而且这些框架之间随便出点参数变更或版本不兼容问题就搞死人。

　　好，总算调正常这一堆框架，我们开发完具体业务应用，我们就开始应用DevOps工具和Docker，进行打包、分发、部署。这么多依赖性的框架，你的微服务能微的了吗？

　　二、云原生应用

　　正确的打开方式是什么呢？让我们描绘一下。

　　第一步：你的代码放在云代码平台而非你公司内部私有部署的Git平台上。这就是微软要花大价钱并购Git的原因。这是第一步。为什么要这样做，你接下来就明白了。反正你现在基于云计算、大数据、人工智能、IOT开发具体业务应用的时候，你大量依赖的都是开源平台，就你那点具体业务应用能有多高技术门槛。而且微软接手后的git，对于企业代码的安全保护、备份，比你自己的管理员和运维技术高多了。

　　第二步：使用云开发平台。这个开发平台可以基于Web浏览器，也可以基于本地VSCodeIDE，但云开发平台的核心本质是：你根本不需要在本地安装那么多依赖框架，你在IDE里面写应用，你打开云上Git平台上面的某个源代码文件，import进一个包，然后在IDE里直接调用API，这个云开发平台会自动补全API，你可以保存代码、你可以编译代码、你可以调试代码、你可以运行代码，和你本地一样，但其实是应用运行在云端，应用也是在云端进行打包、安装部署的。

　　这才是真正的云开发平台，比如AWS的Cloud9。现在有很多李鬼，把20多年前雅奇MIS的那套玩法又拿了出来，快速可视化设计输入表单，图形化进行审批工作流设置，快速可视化设计报表图表，这个东西在全世界也没有独立市场存在过，而且也不是今天我们谈到的云原生应用开发路径上的东西，或者换句话说，那根本不是给开发人员用的。

　　第三步：使用云服务OpenAPI。云计算厂商把所有的云服务都开放出来OpenAPI（你想想Amazon的六个天条），你可以在这个云开发平台上直接调用这个云计算厂商的所有OpenAPI开放平台里面的API。这些云服务会自己负责自己的安装部署升级、监控、备份、迁移等等。

　　三、终极：Serverless

　　最终极的方式是：Serverless。那个时代的IaaS、技术PaaS、应用PaaS、具体业务应用SaaS很丰富，大家都开放Openapi，也有Slack、企业微信、钉钉这样的统一门户平台，也有小程序UI前端技术，你打开WebIDE，New一个函数，里面直接调用OpenAPI，你的应用功能就串联起来了。

　　你也不用在意什么打包、安装部署等细节。当你要运行时，在云端后台，会自动启用一整套DevOps/Docker工具集给你打包，会根据自己的云计算资源给你具体进行安装与部署，你根本不用管是部署到哪个服务器上了。随着你的应用性能，他会去给你自动迁移扩展到更高性能的计算环境中。这一切对于你来说都无感。你每月只需要缴纳一笔总费用即可。

　　不这样推，开发人员的效率提不上去；不这样推，软件公司只使用云厂商的云硬件资源，其他软件中间件都自行开源部署而不使用云中间件，那样云计算厂商也不容易挣大钱啊，毕竟硬件都是刚性成本，只有软件才是高利润的，尤其是云上部署的分布式中间件服务，更是大规模高利润的。