0%

云计算与云原生概览

云计算

云计算的概念

  • 对于云计算的理解基本上可以认为是资源到架构的全面弹性
    • 资源一般特指 CPU(计算)、Mem(存储)和 IO (网络)三大资源,云计算的做法就是将闲置的这些资源充分利用起来,租给用户使用,尤其是可以提供弹性的服务提供
      • 所谓的云计算的弹性可以包括时间灵活性与空间灵活性
        • 时间灵活性:想什么时候要就什么时候要,需要的时候一点就出来了
        • 空间灵活性:想要多少就有多少。需要一个太很小的电脑,可以满足;需要一个特别大的空间例如云盘,云盘给每个人分配的空间动不动就很大很大,随时上传随时有空间,永远用不完,也是可以满足的

云计算的发展过程

Iaas的实现(资源层面的弹性)

物理设备阶段

  • 这个阶段内,就是无脑堆硬件,客户需要一台电脑,我们就买一台放在数据中心里(其实一般学校的机房就是这样的模式)

  • 然而物理设备不能做到很好的灵活性

    • 首先是它缺乏时间灵活性。不能够达到想什么时候要就什么时候要。比如买台服务器、买个电脑,都要有采购的时间。如果突然用户告诉某个云厂商,说想要开台电脑,使用物理服务器,当时去采购就很难。与供应商关系好的可能需要一个星期,与供应商关系一般的就可能需要采购一个月。用户等了很久电脑才到位,这时用户还要登录上去慢慢开始部署自己的应用。时间灵活性非常差。
    • 其次是它的空间灵活性也不行。例如上述的用户需要一个很小很小的电脑,但现在哪还有这么小型号的电脑?不能为了满足用户只要一个G的内存是80G硬盘的,就去买一个这么小的机器。但是如果买一个大的,又会因为电脑大,需要向用户多收钱,可用户需要用的只有那么小一点,所以多付钱就很冤

    补充其他的一些典型问题

    (1) 设备采购、机房网络规划、系统以及软件的安装、虚拟化等工作都需要非常专业的人员来管理。

    (2) 资源利用率问题。通常各个业务部门会在每季度进行项目预算,之后IT部门统一进行硬件采购,而各个业务部门往往是按照峰值甚至是未来的峰值过度申请资源。使得资源在日常的利用率非常低。

    (3) 在一些业务出现迅速发展的情况下,采购的设备很快就用完了,然而资源的整个重新审批、采购、上架,以及配置过程往往需要一个月甚至更长的时间,严重制约业务增长。

    (4) 机房的可用性很难保障。且不说异地多中心的实现难度,单是机房断电切换UPS的过程也会造成闪断,机器重启等问题。

    (5) 在IDC部署的应用架构往往比较落后,也很难满足快速增长的业务需求。

虚拟化阶段

  • 为了解决两个灵活性的问题,引入虚拟化技术,从物理的CPU、内存、硬盘中虚拟出一小块来给客户,同时也可以虚拟出一小块来给其他客户。每个客户只能看到自己的那一小块,但其实每个客户用的是整个大的设备上的一小块。如果事先物理设备都准备好,虚拟化软件虚拟出一个电脑是非常快的,基本上几分钟就能解决。所以在任何一个云上要创建一台电脑,一点几分钟就出来了,就是这个道理
  • 典型的虚拟化技术包括VMware的虚拟化与Xen、KVM、Hyper-V
    • VMware公司的虚拟化技术是闭源的,后两者是开源的
    • VMware公司不仅仅在虚拟化技术阶段大放异彩,在云计算阶段的私有云领域也做了很多

云计算阶段(基础云阶段)

  • 虚拟化软件一般创建一台虚拟的电脑,是需要人工指定这台虚拟电脑放在哪台物理机上的。这一过程可能还需要比较复杂的人工配置。所以使用VMware的虚拟化软件,需要考一个很牛的证书,而能拿到这个证书的人,薪资是相当高,也可见复杂程度

    • 仅仅凭虚拟化软件所能管理的物理机的集群规模都不是特别大,一般在十几台、几十台、最多百台这么一个规模
    • 随着集群规模的扩大,集群管理不能仅仅使用虚拟化这种半人工的手段管理了,必须由机器去完成这个维护过程
  • 解决这种管理困难的方法就是调度,说直白点实际上就是资源的池化或者云化有一个调度中心,几千台机器都在一个池子里面,无论用户需要多少CPU、内存、硬盘的虚拟电脑,调度中心会自动在大池子里面找一个能够满足用户需求的地方,把虚拟电脑启动起来做好配置,用户就直接能用了。到了这个阶段,才可以称为云计算,在这之前都只能叫虚拟化

    • 云计算阶段的龙头目前是Amazon的AWS(公有云),AWS也是闭源的,因此也会有对应的云计算的开源工程–OpenStack,很多IT厂商都加入到OpenStack社区中来,对这个云平台进行贡献,包装成自己的产品,连同自己的硬件设备一起卖。有的做了私有云,有的做了公有云,OpenStack已经成为开源云平台的事实标准(私有云)

      • 事实上AWS在面对后边提到的容器技术的冲击下,相对比较好的兼容了容器技术,而OpenStack相比就差太多了

      image-20210909082358446

      • OpenStack通过数据中心可控制大型的计算、存储、网络等资源池。所有的管理通过前端界面管理员就可以完成,同样也可以通过web接口让最终用户部署资源

Paas(应用层面的弹性)

  • 仅仅是资源层面的弹性显然是不够的,资源必将最终都是要拿来为应用的实现服务的,资源可以快速申请了,但是应用还是需要手动的去部署,因此在Iaas层之上加一个Paas层
  • 对于Paas的理解可以分为两层
    • 自己的应用自动部署
      • 用户自己的业务应用可以自动的在新申请的资源上进行部署,实现应用层面的真正弹性,Puppet、Chef、Ansible、Cloud Foundary都可以干这件事情,最新的容器技术Docker能更好的干这件事情
        • Ansible这些需要脚本的方式解决应用的部署问题,然而不同的环境千差万别,一个脚本往往在一个环境上运行正确,到另一个环境就不正确了
    • 通用的应用自动部署
      • 所谓通用的应用,一般指一些复杂性比较高,但大家都在用的,例如数据库。几乎所有的应用都会用数据库,但数据库软件是标准的,虽然安装和维护比较复杂,但无论谁安装都是一样。这样的应用可以变成标准的PaaS层的应用放在云平台的界面上
        • 比如您是一个做单车的,当然没必要招一个非常大的数据库团队来干这件事情,成本太高了,应该交给云平台来做这件事情,专业的事情专业的人来做,云平台专门养了几百人维护这套系统,您只要专注于您的单车应用就可以了

云原生阶段

  • 在Paas层面上,换句话说就是在应用层面的弹性方面使用的最多的就是容器技术,目前容器技术的代表就是Docker,有了容器,使得 PaaS层对于用户自身应用的自动部署变得快速而优雅
    • 包括后续出现的k8s也可以视作是容器技术栈的一个成员,容器技术的出现(以Docker、k8s、Openshift为代表)标志着云计算进入云原生的阶段(或者说具备了云原生相关技术的基底)
    • 云原生的代表技术包括不可变基础设施、服务网格、声明式API、Serveless等

k8s与OpenStack

  • 二者是当前最火的开源的云计算管理平台,二者的差异点如下:

    • 云服务类型
      • OpenStack更偏向于IaaS,它有能力很好地对我们计算,存储,网络资源的管理,并且以标准服务的方式提供出来
      • k8s更偏向PaaS,其目的是高效的管理服务容器,是一个高效的容器编排引擎,它不仅实现了基本的容器调度,还实现了微服务调度框架
        • Kubernetes 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性, 帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境
    • 可维护性
      • openstack : 难度相对高。有大量的组件依赖,包括依赖mysql, rabbitmq, apache, nova, nova-api, nova-conduction, nova-scheduler, cinder-api, cinder-scheduler, netruon等几十个项目
      • kubernetes : 简单。组件简单, kube-proxy, kubelet, kube-api, kube-shecduler, etcd, controller等10来个项目,所以可以看到它所依赖的组件不会太多,会更好维护。最关键的是kubernetes的很多项目都可以直接运行在容器中,这就意味着你可以不需要去管理你的系统,让系统自动的去解决问题,减少人工成本
    • 资源隔离
      • openstack 隔离性相对较高。完善的多资源的多租户隔离,对vm是针对内核层面的隔离,网络方面是也有一些流量控制工具Linux Traffic Control进行隔离,网络环境用clan,vxlan,gre等进行三层隔离,存储有各自的配额管理,整体来说隔离程度相对教高,其实也是一种面对用户的服务拆分
      • kubernetes 隔离性相对较低。隔离程度相对较低,不支持多租户,对资源池的管理基于resource, 和 namespace,隔离性相对较弱,对具体pods容器的管理基于cgroup,和namespace,不是基于内核层面。所有容器公用内核,隔离性相对较差。
  • 些私有云以及公有云的二次开发是基于OpenStack或者k8s的,也可以是结合二者来做

    • openstack 天生提供了多租户,这对于kubernetes来说是非常重要的,我们完全可以在openstack的环境中搭建Kubernetes服务,提供对多租户的服务支持,由openstack提供基础设施,包括基础服务vm, 负载均衡, 路由器,流量控制,租户管理等高级功能,由kubernetes实现容器编排

      • 不过这种情况下,最好openstack 的网络模式用vlan隔离,否则相当于overlay上做overlay,网络性能会下降很多, 也可以让kubernetes网络模式走netruon,减少性能消耗

      • 对多组户的理解(可以认为是一种偏IaaS的理解)

        多租户是一种单个软件实例可以为多个不同用户组提供服务的软件架构。软件即服务(SaaS)就是一种多租户架构。

        云计算中,多租户也可以指共享主机,其服务器资源将在不同客户之间进行分配。

        与多租户相对应的是单租户,单租户是指软件实例或计算机系统中有 1 个最终 用户或用户组。

        多租户应用通常包括对租户提供一定程度的定制,例如定制应用的外观,或允许租户决定用户的具体访问控制权限和限制

    • openstack 服务用kubernets服务管理。 大家都知道openstack的服务默认是非容器化的,要运维好openstack就需要管理好他们的基础服务,包括mysql, mq, apache,网络组件等相关服务,这需要一套高效的自动化运维系统,而如果用kubernetes去管理opensetack基础服务,像mq, apache, 网络组件,那么运维就可以不去关心了,一切都交给kubernetes就好了

Saas(软件层面的弹性)

  • Paas的过程实际上就是构建一个可能的软件的过程,使用PaaS进行应用构建后的最终服务产品,可能是一个在线服务的形式出现的,这就是所谓的SaaS

云部署的类型

  • 前边说了,云计算的本质就是提供云上的计算资源,这些资源该放在哪,以及怎么放,这就涉及到云计算资源的部署类型,根据放的地方不同,可以分为公有云、私有云和混合云

    • 公有云就是放在一个公共的地方,这个地方有个术语叫云服务提供商,这一般都是大公司,小公司还玩不转;

      • 公有云一般为云服务器提供商所拥有和运营,包括所有硬件、软件和其他支撑性基础设施资源,通过 Internet 向用户提供其资源,用户可以通过 Web 等方式来访问这些资源。业界比较有名的公有云厂商有:Amazon AWS、Microsoft Azure、Google Cloud、阿里云、腾讯云、百度云、UCloud 等
    • 私有云则是放在企业内部,一般供自身业务需求(是否可以将公有云理解成ToC而私有云理解成ToB?);

      • 私有云是专供一个企业或组织使用的云计算资源,一般部署在自家数据中心上,也可以付费给第三方的提供商托管。在私有云中,通过专用网络来维护其服务和基础结构,因而安全性会比较高。业界比较有名的私有云厂商有:VMWare、Nutanix.、深信服、华为云、青云等

        • 使用私有云的用户往往很有钱,自己买地建机房、自己买服务器,然后让云厂商部署在自己这里(把虚拟化和云化的这套软件部署在数据中心里面)。VMware后来除了虚拟化,也推出了云计算的产品,并且在私有云市场赚的盆满钵满—–对应的开源产品OpenStack是开源领域的私有云的事实标准
      • 相对于公有云,私有云有以下几个特点

        • 只有底层的物理机管理系统是统一的,而上面的多个平台是分离的。而公有云上,云平台是统一的。
        • 平台是分离的。这可能有几个原因,一是管理因素,每个平台往往由不同部门在管理和使用;二是运维因素,把平台都放在一起,运维团队搞不定这个单体平台的运维,必须分而治之;三是技术因素,私有云领域还没出现象AWS和阿里云这种能把这几个平台纳管在一起的统一云平台;四是在某些企业里限于等保和安全的需要,某个大业务需要独占资源池。
        • 除了基础云平台是在虚拟机级别实现多租户外,其它平台往往只是在管理平台层面实现了多租户,或者业务层面自己实现了多租户,而下面是一个或几个大的资源池
        image-20210909102706142
      • 私有云环境中和公有云环境中,这些服务(其实应该称为应用服务,与基础服务分开来)的创建和管理方式迥然不同。在公有云环境中,因为多租户需求,云供应商需要提供这些服务的创建和管理服务,使得用户自行创建、管理和销毁这些环境。但是,私有云中,并没有那么多需求,需要反复地创建和销毁这些服务的运行环境。因此,在以OpenStack为代表的私有云平台中实现容器平台、大数据平台的自动化创建和销毁服务这种需求不那么强烈,甚至可以认为是伪需求。针对这些新应用,OpenStack的使命首先应该是让它们在自身平台上『运行好』,而不是『把运行环境创建好』

    • 混合云则是两者融合起来,公有云服务体量大的业务,私有云负责数据的安全。

      • 混合云组合了公有云和私有云,通过技术手段支持数据和应用程序在两者之间迁移,能够为企业提供更大的灵活性和更多的部署选项
      • 企业为了满足安全合规、成本优化、提升地域覆盖性和避免云厂商锁定等需求,会选择多个云厂商。混合云 / 多云 架构已成为企业上云新常态
        • 可以查看阿里云的容器服务ACK就提供了完备的混合云k8s治理能力
  • 除了上边的比较粗放的划分之外,近年来开始把云部署与面向的专用场景结合起来,譬如把和政务相关的资源放一块,形成政务云,跟金融相关的放一块又形成金融云,类似的还有视频云、音乐云、直播云等

云服务的类型

  • 根据提供的服务类型的不同,可以将云服务分为:
    • IaaS(基础设施即服务)
      • IaaS 提供的是比较底层(基础设施)的云计算服务,如服务器和虚拟机、存储空间、网络和操作系统,用户可以根据自己的需求租用特定的资源即可,云服务提供商管理和维护着这些资源,用户只需要购买、安装、配置和管理所需的软件,就可以构建自己的业务系统
        • 一般比较适合于中大规模企业
      • 比如去阿里云上买一个ECS云服务器、DigitOcean等等
    • PaaS(平台即服务)
      • PaaS 则可以按需提供开发、测试、交付和管理应用程序所需的环境,包括中间件和数据库相关的基础结构。用户可以专注在自己的业务逻辑上,无需关心环境的问题,因为一切都就绪,你就开干就行了
        • 一般适合于个人或小规模的企业,抽象掉了硬件和操作系统细节,可以无缝地扩展(scaling)。开发者只需要关注自己的业务逻辑,不需要关注底层,直接像搭积木一样,搭建业务流即可
      • 比如Openshift
    • SaaS(软件即服务)
      • SaaS 则是提供实在的软件服务,一般用户通过订阅的方式来使用软件,随时随地都可以在云上使用现成的软件,无需下载安装,也无需关心软件升级和维护问题,因为这一切在云端都已经帮你做了
        • 具有普适性,不管是个人,还是任何规模的企业,都有使用现成的各类软件的需求,软件的开发、管理、部署都交给第三方,不需要关心技术问题,可以拿来即用。普通用户接触到的互联网服务,几乎都是 SaaS
      • 比如云游戏、DropBox、Google Docs等等
  • 如果再细分的话,类似的还有 DaaS(数据即服务)、SDNaaS(SDN 即服务)、CaaS(容器即服务)等

image-20210908150106282

云计算的分层架构

  • 从技术以及使用者也就是租户的角度可以分为以下两种不同的分层架构

    image-20210908191546911
    • 从技术视角看,计算、存储、网络等底层基础设施构成硬件资源层,虚拟化层通过虚拟化技术,并根据上层应用需求分配、编排和管理着这些资源,为了让资源具备高可用、高可靠,以及可扩展等特性,增加相应的中间层来支持,最上层则提供 Web 等友好控制台给用户,以 RESTful API 的方式展示资源,提高用户体验
    • 而从租户视角来看,租户根据自身业务的需求,如高可用,和所属业务领域,如游戏,依据不同的业务逻辑,来申请使用资源。这种方式能够很好隔离资源的提供者和使用者,提高了灵活性,让资源能够得到最大化的利用

云原生

为什么需要云原生

  • 云计算阶段的传统应用开发不具备很高的敏捷性:在云计算阶段虽然业务已经上云,但是业务形态仍然是传统的单体应用,发布周期长,而且代码改动造成的影响也比较大。因此,需要对应用进行微服务化改造来获得更高的敏捷性,对应的相应的基础设施架构也需要从虚拟机部署改为容器化部署
  • 集群运维困难:其次,把云上的计算资源简单地看成是固定的虚拟机去管理,在服务器的整个生命周期中,会经历无数次的发布、变更和调试。同一集群的服务器之间的配置变得越来越不一致,集群各个服务器出现的问题也不一样。这种配置不一致导致我们调试bug,或者想要对集群进行扩容的时候效率非常低。运维成本也会随着机器的增加而增加。
  • 云计算没有实现最大弹性:第三,虽然迁移上云有利于降低企业采购基础设施,以及建设和运维的成本,但在IDC中面临的资源利用率的问题在上云之后并没有明显改善(并没有实现最大程度上的资源的弹性分配),计算资源依然是要按业务峰值再加一定的缓冲来申请,甚至为保证业务稳定性要预留较大的资源缓冲。再加上服务器申请交付流程麻烦(审批,环境初始化,部署流程配置,监控配置等),因此业务申请机器之后为了防止后续再重新申请,不会轻易回收已经申请到的服务器,从而在资源使用上仍然存在极大的浪费

云原生的概念

  • 云原生脱胎于云计算,云计算的提出主要解决的还是物理资源上云的问题(应该说更多的是侧重IaaS的层面),通过虚拟化技术来将底层资源池化,达到弹性、可控等目的,在资源实现最大复用之后,自然而然的想到IaaS以上的系统也需要统一,进一步降低企业运营成本

  • 大多数传统应用并不是面向云环境来构建的,这里面包含了大量开发需求(开发框架、类库、后端服务等),就导致了云端的强大能力没有被完全发挥出来。因此,摒弃传统的应用技术架构,基于云的特点重新构建云原生应用,成为企业上云的下一个阶段;云原生应该更侧重于PaaS维度

    • 云原生的重点在于所谓的原生,指的是应用的开发应该是面向云的开发
    • 容器技术的出现(以Docker、k8s、Openshift为代表)标志着云计算进入云原生的阶段(或者说具备了云原生相关技术的基底)
  • CNCF对于云原生的定义为云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API

    • 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生所代表的不仅是一系列技术栈,而且还包含了DevOps等一整套应用开发、部署、运维流程,因此它的到来会对企业软件应用产生巨大影响
  • 从技术的角度,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的 非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、 可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点—–阿里云云原生白皮书中的定义

    • 任何应用都提供两类特性,功能特性与非功能特性功能性特性是真正为业务带来价值的代码, 比如如何建立客户资料、如何处理订单、如何支付等等;即使是一些通用的业务功能特性,比如组织管理、 业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值,但通常 又是必不可少的特性,比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发 布能力等等
      • 云计算聚焦解决的就是非功能特性的剥离与解决

    今天大部分的编程语言中, 都有文件、网络、线程等元素,这些元素为充分利用单机资源带来好处的同时,也提升了分布式编程的 复杂性;因此大量框架、产品涌现,来解决分布式环境中的网络调用问题、高可用问题、CPU 争用问题、 分布式存储问题 ……
    在云的环境中,比如“如何获取存储”变成了若干服务,包括对象存储服务、块存储服务和没有随机 访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面,还在于云产品在这些 OpenAPI 或者开源 SDK 背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理 了,应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题,也不 用处理当业务峰值到来时如何对存储节点进行扩容的问题,而应用的运维人员不用在发现 zero day 安全 问题时紧急对三方存储软件进行升级 ……

云原生技术

容器

  • 因为Docker是事实上上的容器标准,因此查看Docker的相关文档
  • 容器技术以及k8s的编排应该视为云原生中的基础技术

Service Mesh

  • 对应云原生架构中的Mesh化架构模式

    • Mesh 化架构是把中间件框架(比如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件 也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分,Client 通常很少变化,只负责与 Mesh 进程通讯,原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成
      • 实施 Mesh 化架构后,大量分布式架构模式(熔断、限流、降级、重试、反压、隔仓……)都由 Mesh 进程完成,即使在业务代码的制品中并没有使用这些三方软件包;同时获得更好的安全性(比如 零信任架构能力)、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。
      • 将那些微服务间的连接、安全、流 量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相关治理问题而聚焦于业务逻辑本身
  • 可以结合云原生微服务的第三个阶段去理解

  • Service mesh作为一种架构设计理念也被应用在微服务框架的实现中

  • 开源实现–Istio

    image-20210910223652054
    • Service A 调用 Service B 的所有请求,都被其下的 Proxy(在 Envoy 中是 Sidecar) 截获, 代理 Service A 完成到 Service B 的服务发现、熔断、限流等策略,而这些策略的总控是在 Control Plane 上配置
      • Istio 的主要组件包括 Pilot(服务发现、流量管理)、Mixer( 访问控制、 可观测性)、Citadel(终端用户认证、流量加密)
      • Istio 有望成为 Service Mesh 的事实标准,而 Service Mesh 本身也将成为容器服务技术的标配技术组件。即便如此,Service Mesh 目前在市场仍处于早期采用 (Early adoption) 阶段

云原生微服务

  • 对应云原生架构中的服务化架构模式

    • 通过服务化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩 缩容,从而使得整体的部署更经济。此外,由于在进程级实现了模块的分离,每个接口都可以单独升级, 从而提升了整体的迭代效率。但也需要注意,服务拆分导致要维护的模块数量增多,如果缺乏服务的自 动化能力和治理能力,会让模块管理和组织技能不匹配,反而导致开发和运维效率的降低
  • 微服务模式将后端单体应用拆分为松耦合的多个子应用,每个子应用负责一组子功能。这些子应用称为“微服务”,多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立,通 过解耦研发、测试与部署流程,提高整体迭代效率。此外,微服务模式通过分布式架构将应用水平扩展和冗余部署,从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷

  • 关于微服务需要注意以下几点

    • 微服务的横向关系
      • 服务发现与服务交互
        • 服务发现需要引入第三方服务注册中心来满足服务的可发现性;特别是对于大规模微服 务集群,服务注册中心的推送和扩展能力尤为关键
        • 服务交互方面,服务之间的调用需 要采用与语言无关的远程调用协议,比如 REST 协议很好的满足了 “与语言无关”和“标准化”两个重要因素, 但在高性能场景下,基于 IDL 的二进制协议可能是更好的选择
    • 微服务的纵向关系
      • 微服务的设计应当尽量遵循无状态设计原则,这意味着上层应用与底层基础设施的解耦,微服务可以自由在不同容器间被调度。对于有数据存取(即有状态)的微服务而言,通常使用计算与存储分离方式,将数据下沉到分布式存储,通过这个方式做到一定程度的无状态化。
  • 云原生微服务架构的四个阶段

    1. 应用除了需要实现业务逻辑之外,还需要自行解决上下游寻址、通讯,以及容错等问题。随着微服务规模扩大,服务寻址逻辑的处理变得越来越复杂,哪怕是同一编程语言的另一个应用,上述微服务的基础能力都需要重新实现一遍

    2. 引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化,形成独立服务框架。但是随着服务框架内功能日益增多,用不同语言的基础功能复用显得十分困难,这也就意味着微服务的开发者被迫被绑定在某种特定语言上,从而违背了微服务的敏捷迭代原则

      image-20210910214320445

    3. 引入Service Mesh的架构设计理念,原来被模块化到服务框架里的微服务基础能力,被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决,微服务基础 能力演进和业务逻辑迭代彻底解耦

      1. 边 车(Sidecar)进程开始接管微服务应用之间的流量,承载第二代中服务框架的功能,包括服务发现、调用容错,到 丰富的服务治理功能,例如:权重路由、灰度路由、流量重放、服务伪装等
      2. 自己的理解是前期使用的是框架实现微服务的基础功能,但是引入service mesh后,微服务基础功能的实现抽离成了一个独立的进程而不是sdk

      image-20210910214335595

    4. 引入Serveless来实现微服务架构,在这个架构中,微服务进一步由一个应用简化为微逻辑(Micrologic),从而对边车模式提出 了更高诉求,更多可复用的分布式能力从应用中剥离,被下沉到边车中,例如:状态管理、资源绑定、链路追踪、事 务管理、安全等等。同时,在开发侧开始提倡面向 localhost 编程的理念,提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异,进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构(Muti-Runtime Microservices)。

      1. 与第三阶段的图对比,可以发现主要的区别在于底层不再是运行应用的容器,而是统一的faas层
  • 微服务架构一般包含下列组件:服务注册发现中心、配置中心、服务治理、服务网格、API 管理、运行时监控、 链路跟踪等。随着 Kubernetes 的流行,Kubernetes 提供的基础部署运维和弹性伸缩能力已经可以满足多数中小企业的微服务运维要求。微服务与 Kubernetes 集成会是一个大趋势

    • 服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心问题。随着云原生技术的发展,服务发现领域出现了两个趋势,一个是服务发现标准化(Istio–服务网格),一个是服务下沉 (CoreDNS);配置管理领域也有两个趋势,一个是标准化(ConfigMap),一个是安全 (Secret)
  • 当前流行的微服务技术就是Apache Dubbo、spring cloud等等

serveless

  • 对应云原生架构中的serveless模式

    • Serverless 将部署这个动作从运维中收走,使开发者不用关心应用在哪里运行,更不用关心装什么 OS、怎么配置网络、需要多少 CPU …… 从架构抽象上看,当业务 流量到来、业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭、调度业务进程,等待下一次触发,也就是把应用的整个运行时都委托给云

    • serveless包含以下特征

      • 全托管的计算服务,客户只需要编写代码构建应用,无需关注同质化的、负担繁重的基于服务器等基础设施 的开发、运维、安全、高可用等工作;

      • 通用性,结合云 BaaS API 的能力,能够支撑云上所有重要类型的应用

        • 一个自己曾经的例子就是,使用函数计算构建应用时,简单一行代码,就可以使用云平台的oss服务,读写其中的文件

        BaaS:随着以 Kubernetes 为代表的云原生技术成为云计算的容器界面,Kubernetes 成为云计算的新一代操作 系统。面向特定领域的后端云服务(BaaS)则是这个操作系统上的服务 API,存储、数据库、中间件、大数据、 AI 等领域的大量产品与技术都开始提供全托管的云形态服务,如今越来越多用户已习惯使用云服务,而不是自 己搭建存储系统、部署数据库软件。

      • 自动的弹性伸缩,让用户无需为资源使用提前进行容量规划

      • 按量计费,让企业使用成本得有效降低,无需为闲置资源付费

    • 目前的serveless还没有做到适合任何类型的应用

      • 函数编程以事件驱动方式执行,这在应用架构、开发习惯方面,以及研发交付流程上都会有比较大的改变
      • 如果应用是有状态的,云在进行调度时可能导致上下文丢失,毕竟 Serverless 的调度不会帮助应用做状态同步
        • 存储计算分离应该可以解决此问题
      • 如果应用是长时间后台运行的密集型计算任务,会得不到太多 Serverless 的优势
      • 如果应用涉及到频繁的外部 I/O(网络或者存储,以及服务间调用),也因为 繁重的 I/O 负担、时延大而不适合
        • 细颗粒度的函数运行也引发了新技术挑战,比如冷启动会导致应用响应延迟,按需建立数据库连接成本高等
    • Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务

  • 函数计算就是serveless的代表技术。关于serveless应该可以参考阿里云中的函数计算(FaaS)的案例、以及阿里云的弹性容器实例、Google开源的基于k8s的serveless应用框架Knative

  • 微服务框架的最新阶段也使用了serveless的技术

  • Serveless的常见使用场景

    • 大前端:App、小程序的后端实现,这类服务业务逻辑复杂多变,迭代上线速度要求高,而且这类在线应用, 资源利用率通常小于 30%,尤其是小程序等长尾应用,资源利用率更是低于 10%。Serverless 免运维,按需付费 的特点非常适合构建小程序 /Web/Mobile/API 后端系统,通过预留计算资源 + 实时自动伸缩,开发者能够快速构建 延时稳定、能承载高频访问的在线应用
      • 事实上,对于任何以 API 作为功能透出 方式的平台型产品或组织,例如钉钉、微信、滴滴等等,Serverless 都将是其平台战略中最重要的部分
    • 大规模批处理任务:比如图片转换,加水印服务这样的,如果从机器或者容器层开始构建,用户通常使用消息队列进 行任务信息的持久化和计算资源分配,使用 Kubernetes 等容器编排系统实现资源的伸缩和容错,自行搭建或集成 监控报警系统。而通过 Serverless 计算平台,用户只需要专注于任务处理逻辑的处理,而且 Serverless 计算的极 致弹性可以很好地满足突发任务下对算力的需求
    • 与其他云服务继承,作为胶水应用,通过和事件总线的集成,无论是一方 BaaS 云服务,还是三方的 SaaS 服务,或者是用户自建的系统,所有 事件都可以快速便捷地被函数计算处理。例如通过和 API 网关集成,外部请求可以转化为事件,从而触发后端函数 处理。通过和消息中间件的事件集成,用户能快速实现对海量消息的处理。

DevOps

  • DevOps 就是为了提高软件研发效率,快速应对变化,持续交付价值的的一系列理念和实践,其基本思想就是 持续部署(CD),让软件的构建、测试、发布能够更加快捷可靠,以尽量缩短系统变更从提交到最后安全部署到生产系统的时间

参考