什么叫云原生应用?| 技术头条

戳蓝字“CSDN云计算”关注咱们哦!前端

640?wx_fmt=jpeg

技术头条:干货、简洁、多维全面。更多云计算精华知识尽在眼前,get要点、solve难题,通通不在话下!git


做者:吕建伟程序员

转自:阿朱说
算法


(1)从Function到Service数据库


1、从函数提及编程


我是1993年学习电脑的。学习的开发语言有三种:汇编、C、DbaseIII。小程序


因此在我学习的时候,我并不了解面向对象的代码架构设计和代码编程实现。因此要从字面上来区分函数和函数之间的关系,主要就靠函数命名、放在同一个代码文件里、放在同一个代码目录文件夹里来区分他们之间的关联性。api


在当时函数时代,也没啥异常保护、异常处理、异常日志的函数编写基本原则,因此咱们除了命名之外,主要注重的就是函数的输入数据参数以及格式、输出数据的参数以及格式。浏览器


2、面向对象安全


个人面向对象是用Object Pascal开始的,但真正大量写面向对象代码的时候是使用Delphi,那已是1996年的事情了。


由于有了类这个东西,因此函数就能够物以类聚了。有的函数属于私有函数只能这个类里面才能调用,有的函数属于公有函数能够供外部调用。


可是我那时候使用类还很初级,每每是一个源代码文件中就定义一个类。并且类也没有使用继承,也就是说我全部的类都是平行的,类和类之间经过Public型的公开函数调用才产生了关系。


3、面向接口


Delphi这个开发语言是优美的,它的定义申明和它的详细实现是分离的。


业务功能进一步复杂起来了,过去没什么太多关系的业务如今关系愈来愈紧密了,有些类和类之间的调用就太多了。我就想着重写这块代码,把这两个类进行合并了。但一重写吧,须要动的东西太多了。


用继承、用多重继承的方法来作吧,太麻烦,总要在实现里写一个空函数(就是没有代码但只有函数架子的,以备编译器能语法经过)。后来认识了接口,就用接口定义了,就不使用空函数了,就定义,不实现,编译器照样能经过。


4、面向组件


我是完整经历过面向组件时期的,而且用面向组件技术编写过一整代完整的ERP引用套件。从CORBA技术到COM/DCOM/COM+技术都娴熟学习并使用过。我也是完整经历单机版本到C/S客户端服务器端局域网版本到C/S/S三层架构的。


一开始我用DBaseIII写应用,UI开发、业务逻辑开发、数据库开发都是一个开发语言搞定。


后来用Delphi写C/S应用,就用了SQLServer大型关系数据库,在数据库层就写了很多存储过程和定时JOB任务。但当时业务逻辑代码和UI代码都是运行在客户端,因此这两层之间的分离也并不清晰。


而后写C/S/S三层架构,业务逻辑层独立出来,并且是物理独立部署,这样客户端代码和业务逻辑层代码就必需要完全分开,不能不清不楚地混杂在一块儿了。在那个时候,我才开始大量使用精心的接口设计、对象设计。


由于有了独立的业务逻辑层,那么这些代码(接口/类)什么时候建立对象实例,什么时候释放,这些对象实例要运行在哪一个进程容器中,就有了要求了。于是就产生了组件容器和组件。组件容器来管理组件的全生命周期(安全、建立、并发访问控制、休眠、激活唤醒、计数、摧毁释放内存),组件管理器就来管理组件的注册、发现等。


因此《COM本质论》的做者Don Box说.NET就是更好的COM,我一会儿明白了:对啊,微软的意思是,之后全部的应用都应该运行在组件容器中,无论是单机应用,仍是C/S应用,仍是C/S/S应用,每一个应用都要运行在组件容器中,由组件容器来屏蔽和管理内存的建立与回收,不要把内存的建立与释放直接袒露给开发者,不然开发者技术能力水平不一,有的烂的程序员管理很差内存,很容易就会使应用占满内存并致使操做系统崩溃。


5、面向WebService


哈哈哈,你们好像都没据说过面向WebService,你们好像就听过面向服务。


Web互联网兴盛起来,HTML(UI元素定义)+CSS(UI元素风格定义)+JavaScript(UI元素操做)构成了前端技术。人们又从前端里分离出来XML,成为数据容器。能够用HTTP+80端口进行传输纯文本的XML数据,也能够用UDP、TCP/IP等各类传输协议进行传输。固然,XML还能够被压缩以便更小尺寸在互联网上传输(尤为过去互联网速度很慢),还能够被加密不让人中间截获看到。这些就构成了WebService的一个技术族。


咱们如今要把局域网版本的C/SS/三层技术架构,升级到Web/S/S三层技术架构,那怎么办呢?


因此咱们须要在咱们的组件基础上再包装一层WebService,客户端的AJAX技术就好调用了。因此当时.NET组件技术、EJB技术、.NET组件容器、EJB组件容器中间件,都纷纷原生内嵌支持WebService技术族,让从开发到运行到调用,直接就是WebService技术。这就是SOA:面向服务架构。


(2)微服务


1、物极必反


当时是多么理想啊:一整套J2EE体系,WebService + EJB完美组件模型  +WebLogic SOA组件容器/ESB组件管理器中间件,包括技术架构师。当年是多么多么大的市场啊。


但程序员是实用主义者,怎么简单怎么来。随着第二波互联网创业热崛起(2004年),大干快上才是王道,没钱用开源开干才是王道。


因而,WebService换成了REST、XML换成了JSON、EJB换成了普通的JAVA Class、WebLogic换成了开源的Spring。尤为在2004-2006年,SSH这三驾马车(Structs前端、Spring中间层、Hibernate数据层)真是横行世界。


尤为2004-2006,Google崛起如日中天,Google统一开放了本身的Open API,轻的很。这已是微服务流行的启动了。但这时候还不能称做微服务,能够称做简化服务(WebSerivce)。


2、亚马逊的天条


贝索斯从2002年就亲自制定了亚马逊分布式系统架构六条原则:


一、全部团队的程序模块都要经过WebService接口将其数据与功能开放出来


二、团队间程序模块的信息通讯,只能经过这些接口进行。其余形式一律不容许:不能用动态连接库、不能读取其余团队数据库、不能试用共享内存、不能试用别人模块的后门,惟一容许的通讯方式只有调用WebService。


三、全部的Web Service,毫无例外,都必须从骨子里到表面上都设计成能对外界开放的。也就是说,团队必须作好规划与设计,以便将来把接口开放给全世界的程序员,没有任何例外


四、不这样作的人会被炒鱿鱼


五、一个服务由一个小团队(两张披萨喂饱)负责,从前端到数据,从需求分销到上线运维,全权负责


六、逆向工做法:先定义将来,而后发布新闻稿进行客户探索与交互,再进行实现执行


我看到这六条原则,我也就明白了为啥亚马逊能作成公有云计算领头羊了,我也就明白了在如今Cloud大行其道的时候,亚马逊还一直坚持使用AWS这个品牌(Amazon Web Service)。


我我的认为,从亚马逊全职能小团队、内外一体化原则开放WebSevice开始,服务才真正变小,成为微服务。若是你是个100人的团队,你是一个按专业职能划分的团队,你是一个一年就发布2次的团队,你是一个区份内部调用和外部调用的团队,我相信,你是成不了真正的微服务的。你充其量来讲,只能说,你是一个用了微服务技术却没有实现微服务的团队。


这很好理解。不少程序员用了一生面向对象的开发语言,但从未本身定义过真正的类。这就是中国。


(3)云时代


1、移动时代来了


90年代咱们用C/S,用C/S/S Corba、DCOM/COM+,2000年之后咱们用.NET、EJB/WebLogic,后来咱们又用REST、JSON、Spring。这都是业务逻辑层技术的演进变化历史。


在客户端,却是互联网访问速度愈来愈快费用愈来愈低、屏幕愈来愈大、性能愈来愈高、内存愈来愈大,给客户呈现出来的功能愈来愈多、UI界面愈来愈复杂。你这个时候想作微服务,其实蛮难的,你受不了诱惑,总想给它添加更多的功能,反正客户端性能高、屏幕大,能承载,没坏处。


可是移动时代从2011年在中国开始了。手机网速慢资费高、性能慢、内存小、屏幕小、没有键盘和鼠标只能手指头划屏幕,因此微信从语音消息而非文字消息崛起了(打字输入实在很差打啊)。


小屏幕,无键盘无鼠标,很差输入也很差输出,那么功能就必须简化再简化。这就倒逼业务逻辑层也不能作的太复杂。所以即便没有亚马逊开除人的六大天条轰顶,微服务在移动时代也算真正被大规模流行起来。如今小程序技术依托微信平台(统一客户、IM、支付),让开发、部署、发布更加简化。


由于人人都有了随时随地可访问的智能设备,因此企业比以往任何一个时代都能更容易链接、触达、交互到最终消费者。因此企业应用开始从企业内部管控建设重心转移到链接消费者、与消费者交互、消费者直接下单交易的业务重心。一个软件的应用的使用主体从能够管控炒鱿鱼的员工,转移到了给企业进行买单交易的衣食父母。


衣食父母不能得罪啊,这是要影响销售业绩的啊,因此须要抓住黏住、快速改进。因此为了快,而不要跨专业职能部门协做,因此各个研发团队也都自行改组,从专业职能部门组织形式改形成为亚马逊式的全职能小团队,这更加助推了微服务的实质化落地。


因此,移动化限制倒逼、衣食父母倒逼,这是移动时代才让大规模万金油程序员学会落地微团队、微项目、微功能、微服务。


2、云时代来了


由于企业应用重心已经从可数的企业员工用户转移到了大规模外界的消费者用户,因此高性能并发、海量数据的技术要求立立刻来了。但企业应用开发者一直面对企业内部用户规模,不是互联网企业啊,怎么应对啊,没经验啊。


正好,云时代来了。


提供了分布式对象系统、分布式数据库、分布式大数据技术平台、分布式消息队列中间件。固然,Spring升级成了Spring Cloud,成了分布式微服务中间件。噢耶,终于跨过这个技术门槛了。


别高兴太早了。由于是分布式的,由于是面对海量最终消费者的,因此部署工做成了复杂的了。不像过去作企业内部管理应用,最多也就十来台服务器,人手工都能升级得过来,并且企业员工一下班就能开干。如今都是消费者应用了,消费者都是行为习惯各异须要24x7运行,并且这仍是交易型应用,你还不敢断掉,你还不敢一会儿全升级了你怕出个交易闪失赔不起钱,因此你还须要灰度发布。


这就须要工具了。


因此DevOps在互联网时代、云计算时代才真正流行开。就是由于:海量用户、在线24x7实时运行、交易型、大规模服务器、快速迭代开发发布上线,不得不开发运维一体化。过去运维人员的技术要求性不高,如今运维人员也得有开发技术能力了。


为了更快捷地打包、分发、部署、升级、维护,人们发明了Docker和K8S。Docker能够打包为一个镜像文件、Docker让微服务的版本环境隔离、Docker让微服务在开发期和运行期一致,这让分发、安装部署、升级、运维变动极为简化。


(4)云原生应用


1、微服务不微是由于什么


微服务不微,是不少人的困惑。


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


虽然有了知足海量用户高并发的Spring Cloud分布式微服务中间件、有了知足分布式部署和运维的DevOps(Jakins/Docker/k8s),但微服务仍然不微。


问题到底出哪里了?


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


软件公司嘛,软件代码是咱们的核心资产。因此咱们确定有咱们私有的Git源代码库,部署在咱们公司的IDC机房里面,并且作层层的安全防御以及代码备份机制。


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


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


2、云原生应用


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


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


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


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


第三步:使用云服务OpenAPI。云计算厂商把全部的云服务都开放出来Open API(你想一想Amazon的六个天条),你能够在这个云开发平台上直接调用这个云计算厂商的全部Open API开放平台里面的API。这些云服务会本身负责本身的安装部署升级、监控、备份、迁移等等。


3、终极:Serverless


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


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


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


640?wx_fmt=png


640?wx_fmt=jpeg


福利

扫描添加小编微信,备注“姓名+公司职位”,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!


640?wx_fmt=jpeg


推荐阅读:


640?wx_fmt=png 真香,朕在看了!