作者:lixuefeng
转载链接:https://zhuanlan.zhihu.com/p/74483850
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
-------------------------------------------------------------------------------------------
IT软件技术架构进入云化时代后,新概念、新技术大量涌现。从几年前热火的Openstack、计算存储网络三大虚拟化技术、Iaas平台,到近几年更火热的容器和云原生的相关技术,在云计算这一领域新技术可谓是层出不穷。
我们经常会听到的这些概念,比如容器、docker、kubernetes、微服务架构、Paas平台、服务中台、Devops、云原生等等。这些技术和概念彼此之间感觉是独立的,我们很容易从其中某一个角度学习入手并应用;但是,很多时候,我们会发现这些技术彼此之间又有密切的关联,从文章也好、技术落地应用的场景也好,它们往往又出现在同一个地方。它们之间究竟有什么联系,彼此之间有什么依赖,让人十分的困惑。
在本文中,从这些技术彼此之间的依赖和关系入手,讲述它们在当今软件云化和微服务化时代中的作用,希望读者从这些总结对比入手,对微服务相关的技术体系建立全局性的视野和理解。
1. Docker容器:
docker大部分人都熟悉或者至少是听过。Docker技术在很多技术资料和书籍上,往往会跟虚拟化技术做对比,它们的对比如下:
- KVM等虚拟化技术是在操作系统级别上进行虚拟和隔离,每一个虚机都是独立的OS。
- 而docker是在同一个操作系统中,实现了轻量级的虚拟化。“轻量级的虚拟化”怎么理解呢?看起来docker容器是独立的操作系统,本质上是同一个操作系统中的进程隔离。所以它是轻量级的;从而,docker比KVM更省资源、资源利用率更高。
Docker的设计理念很伟大、作用也很伟大。但是docker的伟大性远不只是体现在“轻量的虚拟化”;docker的伟大性体现在:它实现了:同一个软件发布,在不同的平台上运行。
这个好处是不是很熟悉?这其实就是Java初流行起来的原因。Python语言为了实现这一点,弄出了VirtualEnv,把依赖包都随着程序发布,才解决了多平台运行的问题。Docker的设计很优雅,一个应用都打包成一个image格式,image采用分层技术等等,这部分不是本文的重点,大家希望更深入了解的话,可以参考其他资料。
2. Kubernetes
docker镜像运行起来是一个一个的程序,多个程序合起来做成一个大的分布式应用怎么做呢?
答案很简单,一样的,程序之间互相调用就行。就好比传统的分布式应用,多弄几台服务器,一个服务器上装一个程序,程序之间通过socket或其他协议通信。基于docker的分布式应用也是如此,区别只是网络虚拟化了、CPU和内存资源也虚拟化了。
但是永远不要低估分布式应用的复杂性,举两个例子,想象我们搭建了一套分布式集群,运行了一套分布式应用:
- 这个集群中的某个机器出故障了(断电了、硬盘坏了等等),怎么去排查故障、怎么去修复?
- 这个集群中某一部分业务由于访问量增加,需要扩充支撑能力,怎么扩充?
针对这两个问题,我们很容易想到答案,那就是人过去检查机器、修复或者重装,负载过大了,就改应用的架构,上面套上负载均衡性,采用可扩展的架构。这些都是传统的办法,这些解决办法不好的地方也很明显,就是修复太慢,太费人力、成本高、对业务影响大,想象一个网站,等扩展架构都弄好了,用户也就都流失了。
Kubernetes是容器编排系统,它首要的目的就是为了解决上面这个例子里的两个问题:
- 分布式容器应用的可靠性,在服务器或容器应用出现问题的情况下,自动感知,自动将容器应用在集群内的其他机器里重新运行起来
- 分布式容器应用的可扩展性,通过启动相同的容器应用,自动的提升应用的负载支撑能力。
Google为了压制AWS,把自己的容器运行平台开源出来,成为了现在的Kubernetes,这段历史大家可以搜索了解一下。
3. Paas
云计算的经典理论上讲三大层:Iaas、Paas、Saas,分布是Infrastructure、Platform、Software as a service。其中的Infrastructure指的是硬件资源虚拟化;Platform指的是软件平台,是应用软件运行的基础平台。
为什么经典理论要把Paas这一层单独拿出来?
Saas层是直接面向业务用户的,Iaas层是应用运行的底层物理资源,中间的Paas是应用运行的标准平台,它包括基础数据库服务、基础中间件服务、基础开发框架和开发套件、应用部署、管理和运维服务。通过Paas平台这一层,Saas层更专注于自身的业务实现,运行平台和运行中间件由Paas层提供。
因为前述的Kubernetes的成熟程度以及无可比拟的优势,Paas层的基础架构基本上都是采用Kubernetes。
有时候会听到“中台”这个概念,有数据层(叫做数据中台)、技术组件层(叫做技术中台)和业务层(业务中台)。
中台的概念出自于阿里巴巴。随着企业规模的扩大,集团中形成了大的BU或部门,每个部门负责各自的业务体。这些业务体中有很多通用型的业务模块,把这些通用的业务模块拿出来,形成一个基础的业务层,这个业务层由在组织结构上相对独立的部门来负责,这个部门负责的东西就是中台。这便是中台的起源。
业务层中台这个概念泛化后,又演化出了数据中台和技术中台。现在(2019年)可能各个大型政企集团都在推进其各自的“中台战略”,猜想其背后的一个很重要的原因可能是:这是一次组织结构和权力分配变革的机遇,有机遇自然会有人去推进。
4. 微服务
引述Sam Newman在Building Mircroservices一书中关于微服务的定义:
Microservices are small, autonomous services that work together.
引用前网飞云架构负责人Adrian Cockcroft的定义:
Loosely coupled service-oriented architecture with bounded contexts.
我们这里定义为:微服务是可以独立部署的、小的、自治的业务组件,业务组件彼此之间通过消息进行交互。微服务的组件可以按需独立伸缩,具备容错和故障恢复能力。
由于微服务架构有下面这几个优势,已经成为云计算时代应用的标准架构:
- 支持快速上线。由于业务组件的自治性和独立性,新的功能和应用能够迅速的发布上线,而不用担心对系统其他功能带来大范围的影响和波及。可以通过服务组件重用重组,快速的形成和发布新的应用。
- 支持独立扩容和恢复。针对性的对应用中的某些服务进行扩容,解决性能的瓶颈。可以独立替换或恢复微服务中的某个组件。
快速上线-意味着速度和效率;独立扩容和恢复-意味着系统的安全、稳定、可扩展。采用微服务架构体系的应用在开发效率、稳定性、可扩展性上具备了无可比拟的优势,使其成为云化应用的标准架构。
由于微服务本身就是独立发布、独立部署、自治的、微小的服务,而docker容器也是跨平台、独立运行、小的执行单元。所以容器是微服务架构的良好运行载体。
微服务架构中的核心功能组件包括网关、微服务治理、服务注册、配置管理、限流和熔断、负载均衡、自动扩容、自动故障隔离、自动业务恢复、监控和日志组件等。
微服务架构本质上与容器及K8S技术无关,在Java体系的Spring Cloud就提供了诸如网关Zuul组件、Ribbon负载均衡组件、Eureka服务注册组件、LCM扩容组件、Hystrix业务恢复组件。利用Spring Cloud的能力可以实现一套完善的微服务架构。Spring Cloud有大量的java开发人员所拥护,这是它的优势。但是Spring Cloud的劣势很突出,那就是限制编程语言和编程技术。
Kubernetes提供了服务注册、配置管理、负载均衡、故障隔离、业务恢复、自动扩容等能力。基于Kubernetes的Paas平台又提供了诸如基础数据服务、网关服务、微服务治理服务等基础服务能力。此外,Kubernetes不限制编程语言,社区活跃、功能稳定。所以可以讲,kubernetes和Paas平台是微服务技术的运行平台。
微服务架构对应用运行平台的依赖性很强,一个好的、功能全面、易用、稳定的Paas平台才能发挥出微服务架构的优势。反之,如果没有一个好的Paas平台,应用开发团队的大部分精力耗费在平台的搭建、利用,以及微服务架构的设计和应用维护上。那样的话,不仅没有得到利用微服务架构的好处,反而沉陷于利用微服务架构所带来的技术挑战和劣势当中。
总的来说,微服务架构是一个“重平台、轻应用”的架构,从应用软件整体来看,相比较传统架构,平台的研发投入比重占的很大。利用成熟稳定的商业化Paas平台是成本优的方案。
5. SOA
SOA(Service-Oriented-Architecture)面向服务的架构,是把服务拼装形成应用整体的架构。SOA中的服务是指“可重用的业务模块”。
微服务架构与SOA很像,同样都是将整个应用拆分,形成独立的业务模块的思路。但在许多关键点上,微服务架构与SOA不同。
- SOA很大程度上依赖于基于XML的消息格式和基于SOAP的通信协议,微服务架构大量的依赖于REST和JSON。
- SOA架构中有ESB(服务总线)的概念,ESB负责服务之间的通信转发和接口适配,在SOA实现中,ESB处于核心地位,有很多专业的ESB厂商提供ESB中间件,例如WebSphere ESB、Oracle ESB、Dubbo等。
- ESB本身是非常“重”的技术,在云化软件体系和微服务架构中,强调更轻量级、更迅速、去中心化的技术,所以在微服务架构中,不需要ESB,而通过API网关这样的技术来负责服务接口转发。(由于软件全面云化是一个过程、需要适配、调整来全面完成转变,所以在一段时间内,面对大量的遗留系统,ESB仍然会充当微服务改造过程中用来适配老系统的一个重要组件。)
- SOA的设计思路是把一些组件和服务,通过服务总线组装,形成更大的应用系统(从小到大);而微服务的设计思路是把应用拆分成独立自治的小的服务(从大到小)。
- SOA设计架构强调分层,通常会分为展现层、业务层、总线层和数据层。微服务架构中的服务更松散。
- SOA中的服务不强调业务领域的自治性,微服务架构强调基于领域的服务自治性。
从上述的对比来看,二者的区别基本上都在实现方式上。微服务与SOA本质上是同一种设计思想在不同时代的不同实现。过去在容器、K8S技术没有出现的年代,造就了SOA的实现方式。
6. 云原生
的CNCF(Cloud-Native Compute Foundation,云原生计算基金会)成立于2015年,由Google等大公司牵头,目前有100多家企业成员,其目的是在容器、微服务及devops领域里、通过一系列的规范和标准帮助企业和组织、在现代的云化环境中构建架构一致的应用。
CNCF的Landscape定义了关于Provisioning、Runtime、容器编排、Paas平台、微服务治理等多个容器和微服务相关子领域的开源组件和技术标准。
简单直白的讲,基于CNCF云原生技术开发的应用,能够在业界各个平台里畅行无阻,部署在私有云、公有云里都是一样的技术体系和架构。
从CNCF的Landscope上来看,进入CNCF的Landscope的组件,在功能、稳定性、活跃程度上大体都是业界领先的。
CNCF定义的云原生三大特征:
- 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,并作为应用程序部署的独立单元。
- 动态和自动化管理:通过集中式的编排调度系统来动态的管理和调度。即K8S。
- 面向微服务:明确服务间的依赖,互相解耦。
总结来说,云原生的三大特征是:docker、kubernetes和微服务。此外,云原生强调自动化以提升能够开发效率和运维效率。
7. Devops
DevOps是Development和Operations的组合,重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加迅速和可靠。
Devops与上述的云原生、微服务、容器等技术应用没有直接的关系,可以讲,没有微服务和容器等技术,一样的可以朝着自动化的构建、测试和发布流程上行进。但是,长久以来,devops只是在文化上和流程指导上给出了方向,至于落地的方法论和工具链上,并没有很成功,只是在CI/CD流程的个别环节上独立发展出一些比较成功的产品,例如jenkins及一些自动化测试工具。究其原因,还是在软件应用基础架构上,没有完善的技术支撑和技术体系,软件的运行环境千差万别、软件的部署和维护流程千差万别、软件的形态和架构千差万别,Devops落地需要大量定制化,工具链落地难度很大。
基于容器和Kubernetes的平台提供了云原生应用的标准发布和运行环境;基于容器的微服务架构定义了云原生应用的标准架构。通过这些技术,为软件应用在架构、支撑服务和支持组件、基准平台上进行了标准化;同时通过这些技术,解决了升级、扩容、稳定性、私有云/公有云/混合云统一基础架构等问题。
微服务架构的重要目标就是:快速发布,那么就需要在敏捷文化、自动化工具链上对流程提出了高要求。
在这个基础上,利用devops的自动化文化、协作文化、敏捷文化,在软件的开发、测试、部署、运维流程上,提升了开发效率、降低了沟通成本、提升了部署和上线速度。Devops是云原生应用在开发、测试和发布流程上的必要手段,基于容器的Paas平台和微服务架构,为devops的流行提供了土壤。
总括:
微服务、容器、云原生、Kubernetes、SOA、Paas平台、Devops 之间相互促进、相互依赖、相互关联,它们之间的关系如下: