常用IT系统架构及DevOps介绍

导读

随着业务需求的变化，IT系统架构也随之升级。新的架构对比之前的架构具有何种优势，又存在哪些问题需要解决？在架构演进的过程中，引入云、DevOps等方法，而这些方法又是如何解决架构中存在的问题，助力IT系统架构升级呢？

本次分享主题是《常用IT系统架构及DevOps介绍》，主要内容分为三部分：

• 1. 常用IT系统架构介绍及演进

• 2. 云相关的工具、方法介绍

• 3.DevOps相关工具、方法的介绍

01

常用架构介绍

1.单体架构

单体架构是我们最常用的架构，一个工程代码就对应着一个应用，代码内可以逻辑区分多个业务模块，而这一个应用则往往部署在单个主机上。其优点在于，架构简单，模块之间调用方便，部署方便。

其劣势1）在于代码、功能耦合。当业务模块A遇到问题需要修改代码，而业务模块B同时也调用了模块A的方法，此时修改模块A的很久可能给模块B带来问题。随之，也会给后续的测试带来问题；2）性能易出现瓶颈，单体应用往往部署于单个主机，其性能受制于所安装主机性能。当某一模块的使用量很大，无法有效横向扩展，即便使用集群扩展，也同时扩展了其他模块，导致扩展冗余；3）易出现单点故障，当部署于单台主机上的单体应用，一旦遇到问题，则无法使用，导致单点故障。

2.多实例单体架构

为了克服性能问题，出现了多实例的单体应用。多实例单体应用部署多个应用实例，通过负载均衡将流量分散至各个实例，从而达到性能扩展的作用。

但是用户和单体应用之间存在Session会话，所谓Session会话即为用户和应用之间交互的状态，比如说，登录的状态，而Session会话一般存储在应用内存中，实例之间无法共享。为了解决Session会话，一般使用两种方式，1）IP Hash的方式，将用户IP hash，对应用户被固定分配到特定实例上。2）通过共享Session的方式，将用户的Session会话存放在分布式缓存中，如Redis、Memcache。每当用户访问，应用则会去远程读写Session，从而实现共享Session。

3.微服务架构

随着IT系统架构进一步发展，更多的工程师将，单体应用拆分，拆分成多个子系统，简单的说每个子系统都是一个可运行的代码。拆分的方式也不尽相同，有的通过业务模块拆分，有的通过领域驱动模型来拆分。为了描述起来方便，下面就将微服务成为模块或者服务。

当服务被拆分成多个服务，服务之间会存在相互调用，但是多个服务的部署信息往往是动态易变的，于是服务将自己的部署信息，比如部署主机IP及端口，注册到注册中心，当某服务需要调用另一个服务时，首先去注册中心获取目标服务IP及端口，进而访问目标服务。

当服务数量增多，且一个服务可能需要部署多个实例，如果对单个实例进行配置，其工作量极大，引入配置中心统一配置各服务实例。

为了进一步提高微服务的服务质量，再则实例众多，无法一一检查其状态，故引入Metrcis监控服务质量、服务之间调用状态，例如Skywalking。

而服务网关聚合众多微服务实例，统一入口，同时也可以自定义实现负载均衡、流量控制等功能。

微服务将整体拆分成多个独立应用，其功能自然解耦。当性能出现瓶颈时，可对特定模块进行横向扩展。而微服务，则是天然的分布式架构，很容易解决单点问题。可见微服务应用解决了单体应用的问题。

但其开发的复杂程度暂且不表，其运维难度足以让运维人员望而却步：1）应用调度的复杂性，一套系统具有N个服务，且一个服务有M个实例。如果将N * M个实例部署于多台服务器，部署完之后，还需要检查是否部署成功、运行状态是否正常，其工作量可想而知。2）部署的复杂性，多个服务都需要进行部署、测试、上传服务器，再进行部署。

为了解决以上问题，架构中引入容器技术、容器调度技术等云的技术、工具解决部署、应用调度的问题；引入DevOps流程、工具解决部署的问题。稍后介绍会讲到。

4.ServiceMesh

近两年来，云原生概念兴起，这里说一些私货，所谓云原生，但凡使用Kubernetes技术或其相关技术即为云原生。Service Mesh（服务网格）就是云原生的微服务，其与前面所讲微服务原理上没有本质上的区别。Service Mesh（服务网格）原理如图所示，每个服务的实例都配备了一个Proxy，这个Proxy相当于服务实例的“秘书”，当服务A需要调用其他服务时候，并不直接访问，而是访问“秘书”，由“秘书”转发。相对，当服务被访问，也不是直接被访问，而是先访问其“秘书”，再由“秘书”转发到服务上。

Proxy实现了流量的控制，比如说流量的熔断、限流，服务的发现、注册，服务的配置等一系列的功能。对于开发人员而言，只需专心实现其业务逻辑即可，从而提升开发效率。

02

云相关工具介绍

1.Docker的介绍

我们接下来介绍云相关的技术。

首先是容器化的技术Docker。Docker容器化的技术，源自于Linux Container,为应用提供了隔离的运行环境，可以理解为应用级别的虚拟机。我们传统使用的虚拟机，通过虚拟化技术划分出一片资源，这片资源上安装操作系统，之后可以在操作系统上安装所需的应用。我们知道操作系统是很重的，需要占据大量的资源，如果一个操作系统上只安装一个应用，那会非常奢侈，如果装多个应用，但应用之间却得不到隔离。

但是容器化技术与之区别，应用共用操作系统，但是通过Linux的cgroup和Namespace来隔离，既可以达到环境隔离、资源隔离的效果，也节省了资源。

所以，现在虚拟机技术更偏向于基础设施层，而容器化的技术则偏向应用的层。

在Docker技术里有两个名字，“镜像”和“容器”。所谓镜像，有点类似于咱们平常安装操作系统下载的ISO镜像文件，是一个副本，通过镜像拷贝出来并运行出来的程序，就是容器。这个容器像一个盒子，里面是运行的程序和数据，和其他盒子还有主机里的程序是隔离的。通过一个镜像，可以运行多个相同的容器，这些容器可以使用所在主机的CPU、内存、网络、存储等资源。

如果运行的容器是一个网络应用，需要被访问，但容器和主机是隔离，不能直接访问。我们可以通过命令—port将主机的端口和容器的端口映射，我们通过访问主机的端口就可以访问到容器。与此同时，对于容器没有映射出来的端口，是不能访问到的。

一般情况下，程序和数据都在容器中，如果将容器销毁，容器内所有数据将会被销毁。遇到一些需要保存的数据，我们可以将容器内的目录映射到主机的指定位置，当容器销毁时，数据依然保存在主机目录上，在运行容器时，再次将容器内目录和主机目录映射即可恢复。例如，我们需要部署一个数据库的容器，由于数据需要保存起来，在启动时需要将数据库容器内数据目录映射至主机目录，这样数据则保存在主机上。当数据库容器不慎销毁，我们可以启动一个新的容器，数据目录映射到原先主机目录，即可恢复数据。

网站https://hub.docker.com/上有很多各软件官方提供的容器镜像，例如MySQL、Nginx等常用软件，我们通过一行命令则可启动相应软件，免去了很多安装、配置的工作量。

可以看到容器的优势在于为应用提供了隔离的运行环境，在应用开发、部署的过程中，我们往往会遇到在这台机器可以运行，换另一台机器就不能运行。但是如果将应用构建成镜像，其环境固化在镜像，运行的容器可以保证环境的一致，并与外界隔离，如果镜像容器测试成功，那么容器可以极大概率在不同主机上运行。故Docker的宣传口号称，Build Once，Run anywhere.（一次构建，任意环境运行）

由于容器间隔离性，容器之间不能直接互通，为了打通容器间的的隔离，Docker提供了docker-compose的工具，将两个容器打通。如图所示。

2.Kubernetes的介绍

Kubernetes是一套容器编排调度的平台，在近几年尤为火热，成为了云技术的标配。Kubernetes可以纳管多台主机，利用主机部署容器化的应用。比如，我们需要部署一个容器化的应用，我们只需调用Kubernetes的API，告诉Kubernetes这个应用的镜像仓库地址，镜像名称及版本编号，需要部署几个，相关配置是什么样的，Kubernetes就会自动在主机集群中合适的主机进行部署，过程中无需人为干预。

可以看到，Kubernetes解决了微服务部署时候的调度问题，我们只需输入需要的参数，Kubernetes则会自动帮助我们部署应用。

上面右图是Kubernetes master节点的架构，API Server为资源操作入口，用于接收外界API调用，Controller 为内部管理控制中心，Scheduler是集群分发调度器，ETCD为Kubernetes集群内部状态存储的数据库，其使用是著名的RAFT分布式数据一致性算法。

上面是Kubernetes节点的架构图，其中最重要的一个概念POD，一个POD包含一个或者多个docker容器，同一POD中容器是互通的，可以将POD简单理解为上文提到的Docker Compose。

03

DevOps介绍

所谓DevOps近两年比较火热，其大致的意思为开发Dev、运维Ops一体化，由于微服务涉及大量服务的编译、测试，DevOps则成为微服务的配套工具。

1.DevOps流程

DevOps的思路是通过自动化工具或方法，替代重复的代码编译、单元测试、服务发布工作。

上图的DevOps流程主要分为三大的步骤，代码管理、自动构建和自动部署。

代码管理环

节，需求人员根据业务，提出功能需求，并提交需求管理软件上，例如常用的Jira、禅道还有GitHub或者GitLab的Issue功能，在需求管理软件上，开发人员领取业务需求进行开发工作。当开发完成后，上传代码至代码仓库。代码仓库可以通过WebHook触发持续构建工具（例如Jenkins、CircleCI）的构建流程。

构建流程，持续构建工具首先1）从代码仓库拉取代码，并2）进行编译，编译过程中可能涉及一些依赖，我们可以通过Nexus创建私有的依赖仓库。3）之后，可以运行代码中的单元测试代码，保证代码可用。4）通过SonarQube进行代码的静态检查，生成代码质量报告反馈给开发人员以进一步提高代码质量，5）把代码编译后可执行文件构建成镜像，并上传至镜像仓库中。

自动部署阶段相对简单，上文在介绍Kubernetes已提到，持续构建工具通过API和相应参数，将影响容器部署于Kubernetes集群中。

可以看到在整个过程，需要人为参与的仅为需求人员提出需求、开发人员编写代码并提交，后续的编译、部署等重复工作都交给了自动化工具。整个过程可以根据实际的情况增减DevOps流程步骤，比如，可以增加过程出错，则发邮件给提交代码的开发人员。

可见，DevOps工具解决微服务中代码部署的问题，将繁杂的工作交给了自动的工具来完成。

结语

如今IT系统架构依旧在飞速的发展中，过去或现在使用的架构都会有不同优势和劣势，我们需要根据业务的需求选择IT系统架构，辅之各种工具和方法使之架构更加贴合业务需求。

今天的分享到此结束，谢谢大家！

更多交流：请关注公众号【通信大数据分析及应用】