常用IT系统架构及DevOps介绍

导读

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

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

1. 常用IT系统架构介绍及演进
2. 云相关的工具、方法介绍
3.DevOps相关工具、方法的介绍

常用架构介绍

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

云相关工具介绍

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。

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系统架构，辅之各种工具和方法使之架构更加贴合业务需求。

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

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

常用IT系统架构及DevOps介绍相关推荐

常用的系统架构 web服务器之iis，apache，tomcat三者之间的比较
常用的系统架构是: Linux + Apache + PHP + MySQL Linux + Apache + Java (WebSphere) + Oracle Windows Server 200 ...
【工具篇】云原生架构，DevOps介绍
DevOps介绍软件开发最开始是由两个团队组成: 开发计划由开发团队从头开始设计和整体系统的构建.需要系统不停的迭代更新. 运维团队将开发团队的Code进行测试后部署上线.希望系统稳定安全运行. D ...
安卓linux层,Android 系统架构各层介绍
android的系统架构采用了分层架构的思想,作为android开发猿还是有必要大概了解一下的,先看一下系统架构图 20190626110750560.png Linux 内核 Android 平台的 ...
大型网站采用什么系统架构保证性能稳定性
from http://www.bobd.cn/design/web/Theory/200904/31145.html 千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用 ...
大型网站系统架构分析--转
大型网站系统架构分析原文地址:http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html 千万级的注册用户,千万级的帖子,nTB级的附件 ...
性能测试知多少---系统架构分析
有些事儿一旦放一放就难再拾起来,突然发现<性能测试知多少>这个系列两月没更新,关键时我都不知道啥时候放下的,总容易被各种技术所吸引走,如饥似渴的想学更多的东西,这几天一直有朋友问我为啥不写 ...
大型网站系统架构分析
千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下sel ...
安卓进阶之android系统架构
安卓进阶之android架构安卓进阶躲不开阅读源码和深入了解安卓的底层,这是一篇入门级别的文章,可以对安卓架构有个大体的认识. AOSP与Android系统架构首先要理解andriod和AOSP的 ...
报名 | 美团技术沙龙第64期：美团不同业务场景下的系统架构实践
[美团技术沙龙]由美团技术团队和美团科协主办,每期沙龙邀请美团及其他互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域.从2015年7月举办第一期美团技术沙龙至今,已经吸引了三万多名工程师 ...

常用IT系统架构及DevOps介绍

常用IT系统架构及DevOps介绍相关推荐

最新文章

热门文章