赞
踩
云原生是一条最佳路径或者最佳实践。更详细的说,云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。
云原生的技术范畴包括了以下几个方面:
即云原生,是一种架构、软件开发思想,就是为了让应用程序(项目,MySQL、elasticsearch……)运行在云上的解决方案,叫做云原生(云架构)
云原生特点:
云原生与本地部署的区别(好处):
实现云原生:
采用微服务架构 是 云原生环境的标配,使用云原生模式部署架构项目,项目必须采用微服务架构。微服务架构的项目离开了云原生,部署,运维的效率就大大折扣。
已知的两套微服务架构方案:
云技术发展:
云原生架构理念:
iaas 【Infrastructure as a service 基础设施即服务】
用户:购买服务器,建设机房,DNS,交换机,路由,网络… (硬件环境)
云计算提供商:提供 网络、存储、dns、服务器…服务,用户只需要租用云主机即可,不需要关系硬件建设。
网络、存储、dns、服务器,操作系统 这样服务就叫做基础设施即服务。
思考: 用户购买一台iaas服务? 就相当于买了一台空的服务器。
paas【platform as a service 平台级服务】
在iaas基础上安装一些软件:基础服务软件—MYSQL,RocketMQ,ElasticSearch…作为基础服务
思考:用户购买这样的服务后,此时用户只需要关系项目业务代码开发,基础软件服务不需要自己安安装。
caas【container as a service】
容器就是一个服务,所有的软件服务都运行在容器中
saas【software as a service 软件级服务】
钉钉 (多租户)
微信企业版 (多租户)
OA(多租户)
财务(多租户)
faas【function as a service】,baas 【backend as a service】
函数即是一个服务—微服务架构(按照function拆分)
视频服务提供商(直播)---- 函数收费 (函数运行,收费)
CDN服务商 (视频缓存服务)---- 函数收费
短信服务 — 发一条短信
支付服务 — 函数收费
service mesh
服务网格架构:服务治理—服务限流、服务降级、服务监控…… istio
客户端 --> proxy代理服务–> 服务(集群)
客户端 + proxy(集成在一起:服务治理–降级,限流、监控…)–> 服务 + proxy(集成在一起:服务治理–降级,限流、监控…)(集群)
注意:
一般企业直接使用 proxy代理模式就ok,至于服务治理用 springcloud
service mesh 不建议使用,落地非常困难,技术能力要求很高
serverless
server 服务器,less 无 —> 无服务器,无服务架构
未来开发境界:程序员只需要关心代码业务开发即可,服务器环境不需要关心,所有的服务都上云。
未来:
公有云: 阿里云,腾讯云、网易云,百度云,滴滴云…
私有云: k8s 自己公司构建自己的私有云 ------ 很多公司在使用私有云
要根据云计算类型:私有云、公有云、混合云,来选择适合的虚拟技术
Docker,进程级别隔离,适合:
虚拟化KVM,物理硬件隔离,隔离的更彻底,适合:
公司中:只是用于业开发,实现可持续服务交付,部署 ------- 不需要使用虚拟化技术,直接使用容器化方式,对项目进行测试,部署即可。
即基础设施(iaas)、基础软件级(paas)服务用虚拟技术、软件服务(saas)用容器技术
思考问题:
问题1:物理硬件进行虚拟化处理,使用了很多虚拟机? 庞大的虚拟化集群网络如何管理??
解决方案:Openstack
问题2:docker部署服务(微服务架构:按照function拆分,服务非常之多………),docker容器越来越多………,同时面临很严重的问题,管理庞大容器资源非常困难。
解决方案:k8s对容器进行编排管理
物理机模式: 服务部署在物理机
虚拟机模式: 为了充分利用物理机的计算资源,使用虚拟机方式部署服务
云原生模式: 应用部署在容器中
思考:微服务架构,服务拆分成千上万个服务,就需要非常多的容器来进行部署,那么这些容器怎么管理?
怎么横向扩容?
服务宕机了,怎么恢复,你是如何知道的?
版本更新,上线,更新容器后,线上业务如何不受影响?
监控容器?
调度问题?
安全问题?
window系统:海量的文件,如何管理??资源管理器(管理文件:调度)
虚拟化: openstack
容器化: Kubernetes
解决问题:
以上问题,容器编排技术来说,一个指令,一个按钮就可以搞定一切。
Docker-compose组件可以批量的创建容器,管理容器,粗颗粒度。
非常轻量级容器编排技术,可以通过yaml文件方式,对容器进行批量管理,不能实现复杂容器编排
可视化的容器管理工具,v2版本提供对k8s兼容。中小型使用,性能非常差,不能实现复杂的容器编排。
Swarm容器编排工具是docker公司自己的开发,但是docker公司都不使用,docker公司使用的kubernetes (k8s),阿里云切换为k8s
目前三大主流的容器平台Swarm, Mesos和Kubernetes具有不同的容器调度系统 ;
Swarm的特点是直接调度Docker容器,并且提供和标准Docker API一致的API。
每台服务器上都装有Docker并且开启了基于HTTP的DockerAPI。这个集群中有一个SwarmManager的管理者,用来管理集群中的容器资源。管理者的管理对象不是服务器层面而是集群层面的,也就是说通过Manager,我们只能笼统地向集群发出指令而不能具体到某台具体的服务器上要干什么(这也是Swarm的根本所在)。至于具体的管理实现方式,Manager向外暴露了一个HTTP接口,外部用户通过这个HTTP接口来实现对集群的管理。
Mesos针对不同的运行框架采用相对独立的调度系统,其框架提供了Docker容器的原生支持。 Mesos并不负责调度而是负责委派授权,毕竟很多框架都已经实现了复杂的调度。
Mesos是Apache企业的开源项目,是一个资源管理,用来进行容器的管理。
google研发一套容器编排技术,这套技术没有对外公开,强大,稳定。
google研发一套容器编排技术,使用go开发。性能非常强大、稳定、通过指令、yaml编程方式管理容器,非常灵活。
Kubernetes则采用了Pod和Label这样的概念把容器组合成一个个的互相存在依赖关系的逻辑单元。相关容器被组合成Pod后被共同部署和调度,形成服务(Service)。这个是Kubernetes和Swarm,Mesos的主要区别。
Kubernetes(k8s)是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。
Kubernetes基本结构:
使用Kubernetes可以:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。