经历了九九八十一难,我终于开始进行撰写云原生的文章了,也因为最近事情比较多,导致我的脑子很乱,并不能很好的输出内容,文章更新频率并不是很高,不过就在昨天,终于把一部分的事情解决了,我也打算拿本周来认真写一下文章,这篇文章是这个系列的开始,我们也不会止步于此,这周会先把学习路线搞出来,然后去写一下服务网格这方面的知识,我会尽我最大的能力去讲好这些知识,如果有什么错误的地方也希望大家指正出来,咱们共同进步!
在2006 年,电子商务服务商 Amazon上线了云计算服务 AWS,包括计算服务 EC2、存储服务 S3 和队列服务 SQS。并且对外提供计算、存储资源的租用,以 AWS 的营收弥补在销售淡季服务器所需的各项成本,开创了公共云计算服务的先河。
经过十多年的发展,云计算已经成为如水电气一样人们习以为常的计算资源和计算模式。有意思的是,网格计算的网格(Grid)的概念就是源于 State Grid,其本意是提供一种如电力一样即插即用的普适资源。然而,网格计算主要还是面向科学计算领域,没有经过商业化运作,所以也就没法通过商业变革创造一种新的计算模式 而亚马逊CEO 杰弗里·贝索斯在推出 AWS 时,就坚信要提供一种普适的基础设施服务。从自身角度看,云计算的确具备了如秒级启动、弹性扩容、随时访问等“Grid”所具备的特点。虽然如很多其它新技术一样,云计算起源于美国,但千万不要照搬美国的云计算发展过程到国内复制一套相似的产品。事实上,中国的云计算和云安全发展表现出了鲜明的“中国特色”,这与国内的国情是有密切关系的。
具体而言,美国的云计算发展是先 SaaS 后 IaaS 的阶段。虽然云计算传入中国最早的印象是 Amazon 的 EC2,但事实上 SaaS 是最早的云计算服务形态。然而,中国的云计算发展则是从虚拟化起步,从私有云到公有、行业云,走出了具有中国特色的发展路线。最早在 2000 年以后,VMWare 进入中国时,引入了商业级的虚拟化解决方案,国内企业开始接触到虚拟化技术,当然这远远谈不上云计算,甚至连私有云都不算。
具有里程碑的标志是开源的 IaaS 项目 Openstack 在国内兴起,Openstack是由公有云服务商 Rackspace和 NASA 发起,最初是对标EC2,目标是构建组件化的、开源的公有 IaaS 平台并提供服务。随着国内云计算需求的不断增强,国内厂商EasyStack,华为等企业基于Openstack研发了各自的云平台,此时国内的云计算需求主要是将硬件服务器虚拟化,再加入多租户管理、网络隔离等需求,因而,多数云计算服务商提供的是私有云的解决方案,当然这也比纯虚拟化已经进了一大步。通常商用私有云系统是封闭的,缺乏对网络流量按需控制的应用接口,因而,针对这类私有云的安全机制多为安全资源池,即构建独立的安全资源,然后通过路由、VLAN 或开放网络接口将流量牵引到资源池处理。
可见,云计算应用在 2020 年已经成熟,企业上云已经成为一种默认选项。除了渐进式的产业升级、人们观念改变等因素外,近两年的一些趋势发展,使得云计算接受程度增加、云业务变革到来,具体有以下几点:
综合而言,云服务商提供了成熟的虚拟化基础设施,企业客户也做好了上云的思想、技术和体系的准备,整个云计算的势头已起。
如果说 2020 年云计算的玩家已经踢完了上半场:那么云计算的下半场在哪里,会出现哪些玩家,云服务商、企业客户又将会做什么准备呢。
相信各位这段时间也已经被云原生的浪潮“卷”到了,或多或少都听过这个名字,这里我们要详细说一下的。
云原生包含了两个部分:
云
我们现在不管是做安全还是技术各种方面都是需要用到云,阿里云,华为云,这些都是云平台,现在的云也叫做云基础设施。
原生
原生这个概念不止在这里,在其他的情况下也是存在的,这里举一个例子,比如张三,张三和他的亲生父母组成的就是原生家庭,如果张三被姑姑等这种亲戚领养了,那就不能叫做原生家庭了。在这里原生的意思是能够在云平台上原生的去开发,也就是基于这个云基础设施来开发,运行的。
云原生这个概念是在2013年被Pivotal公司的Matt Stine提出的,并且在2015年谷歌带头成立了云原生计算基金会(CNCF),CNCF的目的也是基于k8s集群生态的所有应用都能发扬光大。
怎么让云原生的概念落地呢,比如之前提出了一个devops的概念,到底什么是devops呢?于是就有人开始落地方案,只有落地了才能有更多人用,环境更完善。
云原生落地的定义
来自一个红帽的技术大牛提出了一个概念:基于微服务原理而开发应用,以容器方式打包*,(到这里,就是原生的概念)*在运行时,容器基于云基础设施之上的平台进行调度,应用开发采用持续交付和DevOps实践(到这里就是云的概念)两个概念加起来就是云原生。
云原生技术有利于各组织在公有云,私有云和混合云等新型动态环境中,构建运行可弹性扩展应用,这些技术构建起来容错性高,易于管理,便于观察的松耦合系统。让工程师轻松的对系统作出频繁和可预测的变更。
综上所述,云原生本质上就是用容器化封装+自动化管理+微服务+服务网格+声明式API实现的。
大家知道,我们的服务分为单体服务(部署到一台主机或者一个进程里面的),比如在一台物理服务器中部署了一个Nginx ,这就是单体服务,如果Nginx或者主机坏了,服务就不能用了,于是分布式服务出现了(在部署过程中,把服务部署到其他主机,一个坏了其他还可以使用)
分布式服务出现之后其实有些服务和单体服务差不多,比如安装一个mysql,我们发现他坏了,最好的情况就是做一个集群,但是如果我们做了一个集群,那就意味着做了一个高可用的mysql架构出来,我们还要进行方便管理,如果纯手工解决很麻烦。所以在这里我们可以把mysql进一步容器化,容器化管理起来,也就是微服务,更小的服务。
微服务定义:原有单体应用拆分为多个独立自治的组件,每个组件都可以独立设计,开发,部署,运维,也可以单独对外提供服务,我们称之为微服务。
其实还有比微服务更小的服务,是我们的serverless,这里就不过多提了。
例如:早期的LNMT web部署架构,使用微服务后每一个组件都可以独立自治,运行,扩容,缩减等。
组件之间可以通过轻量的Restful风格接口进行交互协同, 并且,容器化是微服务最好的载体,而不是虚拟机。
Docker容器,容器基于it基础设施层概念,是比虚拟机虚拟机更轻量化的隔离工具,微服务最佳载体。
使用kubernetes的资源调度和容器编排,可以实现Docker容器更优管理,进一步实现PaaS层能力
如果你学习k8s,需要把pod,容器,app的关系搞清楚,pod就是节点,containerized是容器,app是微服务。我们早期在使用虚拟机就是k8s里的pod,pod提供了环境,container就是容器,里边的应用是微服务。
其实k8s和Docker是有斗争在里面的,感兴趣的可以自己去看一下这两位的故事~
有些小伙伴对于服务网格可能有些陌生了,我这里提一下其他概念,正向代理,反向代理,nginx的反向代理等,如果你能理解这些技术,那你就可以理解服务网格了(不理解也没问题,都可以慢慢来~),服务网格的本质就是一种服务的代理方式。
服务网格的目的,就是去中心化的服务治理框架。
为什么会用到服务网格?
以往对微服务或者api接口做治理和管控会用类似ESB服务总线或者API网关,把API接口注册接入到APi网关,API网关本身是一个中心化的结构,所有请求流量都可以通过API网关,它来实现流量拦截,同时对拦截后的流量进行安全,日志,限流熔断,链路监控等各种管控治理,去中心化之后就没有这种集中化流量管理点了,对流量的拦截就下沉到各种微服务中了,这就是我们为什么要在微服务端增加一个代理包的原因,通过这个代理包做流量拦截,同时实现对流量的管控,服务网格也是用同样的思想来治理的。
比如我后面要写的istio,它会在微服务中添加一个边车容器实现流量拦截和管控,属于服务网格治理的核心技术。
在传统的开发中,如果做一个软件的部署,部署到一个生产环境之后再去做一个变更,不管是应用程序或者配置变更,都需要在原来的环境重新部署,在云原生应用中,你部署一个应用,它会自动生成实例,这个实例不应该再做任何改变,如果要重新配置或者修改的话可以用基础容器镜像重新生成实例,同时把旧的容器销毁,这就是云原生中的不可变技术点。
DevOps在早期提出来的时候仅仅是概念,在早期使用主机的时候落地是很困难的
借助于云原生相关技术,DevOps时代才真正的到来了
1.实现开发,运维,测试协同合作
2.构建自动化发布管道,实现代码快速部署(测试环境,预发布环境,生产环境等)
3.频繁发布,快速交付,快速反馈,降低发布风险
服务编排要实现计算资源弹性。
服务构建和部署要实现高度自动化。
事件驱动基础设施标准化。
云原生应用生态已经覆盖到大数据,人工智能,边缘计算,区块链等领域,发展速度可谓是惊人。
云原生是云计算时代的下半场,或许我们可以称之为云计算 2.0。云原生的出现,与云计算不断与具体业务场景融合,与开发运营一体化碰撞的结果,是一场由业务驱动的对云端基础设施、编排体系的重构。
云原生系统与业务系统运营有很强的关系,又要支撑不断演进的快速开发、快速交付模式,可预见云原生安全除了基础设施安全、IT 运营安全外,将会覆盖应用安全、业务安全、开发安全等内容,而且这些细分的安全功能,应该是通过有机、一致的形式共同作用于云原生环境
创作不易,如果觉得内容对你有帮助,麻烦给个三连关注支持一下我!
目前正在更新的系列:从0开始的蓝桥杯省一之路,云原生系列。
感谢各位的观看,文章掺杂个人理解,如有错误请联系我指出~