首页 > 编程知识 正文

php容器连接数据库(SQL数据库)

时间:2023-05-05 04:51:15 阅读:96848 作者:3695

前几天,高可用架构文章《数据库不适合Docker及容器化的7大原因》(以下简称7篇)在群里引起了一些讨论。我个人有一些不同的看法,但论证可能不是很清晰透彻。后来我说写篇文章回应。所以这篇文章。

这篇文章不仅反驳了这篇文章,还想谈谈应用容器化和云化的价值。看这篇文章的时候,我建议看我上周发的《2016年容器技术思考: Docker, Kubernetes, Mesos将走向何方?》(以下简称激动枫叶)。在这篇文章中,我将直接引用这篇文章的一些观点。

《7文》虽然列出了七个原因,但总结起来,其实主要有两个原因:

容器化的数据库并没有带来多少额外的价值。数据库不需要经常构建和部署,也不需要经常升级。数据库实例的环境不需要经常变化。Ansible也可以轻松部署和设置。

安全、IO、网络等方面的技术成本和风险。引入容器带来的,如果没有必要,不要添加实体。

本文主要从这两点出发,逐一分析。因为本文实际上是在分析一项通用技术的价值,所以我们先来谈谈如何评估一项通用技术的价值。

如何对一项通用技术做价值评估

任何通用技术都承载着一定的技术使命,都有其历史背景和最终目标。对其价值的评价是思考其使命和目标,不能简单地从自身情况出发。

以本文提到的Ansible为例,我向一位技术总监推荐Ansible时,他说Ansible的功能已经由我们自己在shell中编写的一套框架解决了,绝对没有必要引入额外的工具来增加复杂度。我说Ansible可以屏蔽操作系统的细节,使得跨操作系统编写通用配置脚本变得更加容易。他说我们的操作系统是ubuntu,这个功能对我们没有价值。我说Ansible可以将变量从配置脚本中分离出来,提高脚本的可重用性。他说我们的脚本也在一定程度上分离了变量,我们只分离了必要的变量来满足我们当前的项目。我说Ansible文档详细,学习成本低。他说shell脚本可以看源代码,很容易修改。最终,这场争论没有结果,没有人说服任何人。

后来,我一直在想,有什么问题吗?其实每一项技术的推广,无论是工具、框架还是语言,都会遇到类似的争论。后来我意识到,任何通用技术最重要的目标,其实都是增加软件的可重用性,无论是技术本身,还是技术衍生出来的产品。但是如果不考虑复用,应用到具体场景时效果会打折扣,所以我们不能仅凭具体场景来评价通用技术的价值。

以Ansible为例。Ansible本身是一个服务器配置管理工具。它的目标是使服务器配置变更代码(配置管理基础设施作为代码),然后使应用程序安装和配置能力组件化,称为Playbook,然后可以共享和重用。所以可以在网上搜索各种Ansible Playbook,比如数据库集群的安装和配置。为了达到这个目的,它抽象出一套配置语法,通过声明式配置定义服务器上基础设施的状态,在一定程度上屏蔽了操作系统的细节(如果屏蔽不了,也可以通过简单的配置规则进行适配)。同时,它将变量和配置分开,以避免与特定环境耦合。也就是说,只有接受它的核心思想——服务器基础设施变更编码,然后考虑重用价值,重用别人的行动手册或者重用自己的行动手册给更多的项目或者团队,Ansible的价值才能体现出来。比如前面的案例,如果考虑到未来会有更复杂的操作系统环境,可能需要管理的复杂项目会越来越多,从而避免运维人工操作带来的无法追溯的意外变化,那么就值得引入Ansible。

因此,不要只从你当前的业务需求来判断一项通用技术的价值。比如把这篇文章的标题改成《我们当前的数据库不适合 Docker 以及容器化的 7 大原因》,争议就会小很多。看一篇文章,看看是在做具体的选型分析还是一般的价值判断。

00-1010我们再来分析一下数据库容器化的场景。

目前,我们开发的任何软件与用户部署和操作成服务之间都有巨大的差距。以数据库(MySQL/PostgreSQL)为例。厂商交付给用户的是安装包,用户期待的是主从数据库集群,可以支持故障主从切换、自动迁移恢复、自动备份、监控报警。当然,如果有一个仪表盘通过界面操作实现自动升级就更好了,更复杂的需求可能还需要支持读写分离和数据库自动分段。可以看出两者之间有着巨大的差距,这个差距目前由用户的运维人员来填补。

操作人员如何填写?首先从网上找一些技术资料,如何做MySQL主从复制,如何做高可用性(keepalived、虚拟IP等)。),如何做双主,如何通过代理做读写分离,然后把这些组件和脚本绑定,部署到服务器上。当然,这仍然是操作和维护的一个强有力的例子。如果运维力度不够(大部分创业公司无法投入研发;d)在这种基础设施上),他们甚至可能无法做好主从和备份,即使他们已经用脚本编写了一些简单的工具。由于测试不足和考虑不周的环境异常,正式使用时可能会出错,比如前段时间的gitlab数据库删除事件。

简单回顾一下gitlab事件,本来单个节点的数据删除应该不会影响整个集群,但是因为从机数据同步没有完成(所以可以推断从机数据库不应该启用,读写没有分离)

,不能直接升级从库为主库,而其他的多种备份工具都没生效。

这大概是大多数公司的现状,有一些基础设施工具,但基本都是和环境耦合的脚本,也正如《7文》中所说,数据库等基础服务部署后很少需要去做变动,并且随着数据越来越多,越来越不敢动,每次变更,比如升级等,就是一个复杂的工程,差不多要发起一场战役,但一旦出现预期外的故障,就缺少必要的工具和经验去应对。那如何避免这种问题呢?左耳朵耗子的文章《从GITLAB误删除数据库想到的 [1]》提出了一个建议:『设计出一个高可用的系统,通过自动化的方式去处理问题』。

但是这个基础设施的自动化高可用系统,有那么容易设计么?一方面大多数公司受限于研发实力,没时间和精力做这种系统,另外一方面即便是有研发实力,这种系统并不能直接产生价值,如何得到高层的支持?能得到多大资源支持?数据库厂商或者其他商业公司能否提供这样一个数据库服务,再或者能否通过开源项目打造出一个数据库服务,用户可以一键部署?这样就能将各公司的运维经验沉淀成具体的工具和组件。而不是像现在,运维经验的沉淀和传播基本都只能通过技术分享或者人员流动,这对业界是一种很大的浪费。

那我们设想一下,如果要做前面描述的这样一个系统,都需要什么条件?

首先,得有一种应用的安装包的环境无关的封装,如果要适配不同的操作系统,解决不同的环境异构问题,就很难了。

其次,基础环境可编程化,可以在程序中实现网络,存储等环境的动态适配。再次,要有一个调度层,可以做动态迁移。

最后,需要一个编排文件来定义各种组件,以及一种打包格式,将多个组件封装到同一个包中做分发。

Ansible/Puppet 等配置管理工具一直想做这个事情,并想封装成可复用的组件,可惜由于基础设施的环境不统一,不可编程化,而配置管理工具只能一定程度解决部署时的复杂性,应对不了动态的故障,基本很难达到这个目标。

IaaS 云实现了基础设施的标准化,可编程化,可动态调度。所以现在 IaaS 云基本都有 RDS(Relational Database Service),功能和前面的描述的用户需求非常类似。但 IaaS 的问题是当前 IaaS 的 API 基本都是指令式的,是面向资源的,不是面向应用的,第三方很难通过这种 API 来调度应用,所以这种服务第三方很难实现,基本都是云厂商自己定制(IaaS 上也有镜像市场,但只能是单个镜像的应用,不能实现复杂的应用),同时 IaaS 的镜像都是 VM,很难实现跨云的分发。

于是,Docker 出现了。Docker 的镜像,几乎完美实现了前面提到的安装包的环境无关的封装,也就是大家说的集装箱能力,又通过镜像仓库提供了分发机制。上面封装一层编排调度系统(Swarm,Kubernetes,Mesos),再加上标准化的网络和存储,于是基本达到了我们上面所描述的条件。

我在《激动的枫叶》中也论述了

容器平台的最终目标其实是屏蔽分布式系统的资源管理细节,提供分布式应用的标准运行环境,同时定义一种分布式应用的 package,对开发者来说降低分布式系统的开发成本,对用户来说降低分布式应用的维护成本,对厂商来说降低分布式应用的分发成本,也就是 DataCenter OS 或 Distributed OS,可简称 DCOS。

也就是说,仅仅把数据库弄成容器镜像,这仅仅是第一步,是为了后面的目的服务的。有了这一步,才有可能依托容器编排调度系统封装更高级的通用服务。

有了这种能力后,运维的经验就可以沉淀成代码,积累成具体的工具和服务。软件的价值在于复用,可复用的频次越高范围越广,产生的价值越大,越值得投入。比如 RDS 这种服务,研发本身的复杂度本来不高,关键在对各种异常情况的处理方案的经验积累。一个公司遇到的异常状况肯定有限,只有放在社区中逐渐积累改进才会逐渐完备。IaaS 云的 RDS 的优势其实也是这一点,积累了云上的各种用户的各种使用场景和异常处理经验,无论是业务增长还是错误使用带来的异常。前两天 Instapaper 由于MySQL数据文件过大、达到 ext3 的 2TB 文件大小限制,而导致其数据库故障,业务中断31个小时,用的就是 AWS 上的 RDS 。虽然使用 RDS 并不能避免故障,但经过这次故障之后,AWS 肯定会改进 RDS, 将这种故障的应对经验沉淀到产品中去,其他用户就可以避免再次踩坑了。

当然还会有人问,我们当前没有任何精力做更高级的封装,只是把数据库简单的用容器镜像跑起来,还有意义么?也正如我在 《激动的枫叶》中说的,对容器技术可以做渐进式的接纳,第一步先当做安装包使用,第二步考虑隔离,引入网络解决混合部署带来的网络冲突,第三步再考虑调度编排系统。《7文》中也承认了容器在开发测试环境中的意义,既然开发测试环境中可以接纳容器,保持环境的一致性不更好么?我在文章《基础设施服务的微服务化 [2]》中分析了为什么应该将基础服务也作为微服务的组件,一体化管理。只有将数据库等基础设施作为微服务的一个组件,和业务应用的微服务互相可以感知,才能实现最终意义上的全自动化。

当然,只是有了标准化的运行环境,并不一定能带来丰富的应用,还得依赖商业模式。这种基础设施服务原来的商业模式基本只能是 on-premise 私有部署模式,销售和实施成本非常高。企业应用领域是否可能出现一个类似于 Apple 的 AppStore 的市场来降低销售和实施成本? 这方面很多厂商都在尝试,各容器平台都在尝试推出自己的应用规范,IaaS 厂商也在考虑提供声明式的编排 API,让渡出基础设施服务,由第三方实现(比如 QingCloud 即将发布的 AppCenter)。如果这个商业模式成熟,不仅独立的基础设施服务以及中间件公司会涌现出来,同时各公司的基础研发部门可能会从原来的支撑部门,变为 2B 业务的营收部门。

引入容器带来的技术成本和风险

引入任何技术都会带来技术成本和风险,当然容器也不例外。但成本和风险是可以评估的。

安全

IO

网络性能影响

成本

所以说,容器引入的成本和风险相对于收益来说,绝对是可以接受的,即便是它现在存在着许多问题,但绝对是一个潜力股,值得投入。

总结下,对技术的接纳很多情况下其实是纯粹的观念问题。最初 IaaS 出来的时候,不也有很多人说,数据库服务不适合跑在虚拟机上了,大数据服务不适合跑在虚拟机上了,现在不也有很多用户用的很好。合适不合适,脱离具体的业务场景和需求,是说不清楚的,对于大多数用户和产品来说,数据库的易用性,易维护性,可用性,要大于性能等其他方面的要求的,对另外一部分用户来说,数据库肯定要跑到物理机上,甚至 PC 服务器都不能满足。所以还是不要仅仅从自己的当前的业务需求来断定一个技术通用价值。

本文链接

http://coolshell.cn/articles/17680.html

http://jolestar.com/infrastructure-service-as-microservice/

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。