创意电子

标题: 数据库架构面面观 [打印本页]

作者: 数据库技术达摩院 时间: 2020-11-4 13:30
标题: 数据库架构面面观
作者：韩锋

本文为近期加入dbaplus社群在线直播活动摘录。作为一个数据库领域资深从业者（好吧，我是个70后）。近些年来，重要从事数据库产品、架构等工作。下面将以我个人感受，谈谈数据库架构工作的多方面影响因素及发展、实践话题。盼望能给大家带来些思考。

<hr>

ONE环境篇

下面的分享，将从外部环境对数据库架构的影响？当前架构中若干热门的技术问题？之前的一点架构实践经历及个人如何发展等方面谈谈感受。

首先谈下外部因素对架构工作的影响。有些同砚，可能会感到疑惑，架构问题不是技术问题嘛？为什么还要考虑外部因素？这里是有个误区的，架构的本质是为了解决企业的业务问题，针对某一问题可能有很多种解法，选择最为合适的（而非最优的）是检验一个架构师的核心本事。正如上图中右下角所描述的，“脱离企业环境的架构，都是耍流氓”。那么影响架构的外部因素有哪些呢？

1).单元属性
单元属性，包括企业、事业、军工等。差别单元属性，对架构诉求点是有差异的，粗浅的理解企业单元是寻求利益最大化的、事业单元更多会从公共视角考虑问题、而军工则会从国防安全角度思考。

2).行业属性
行业属性，包括互联网、金融、制造业、能源、交通等等。差别行业属性，同样存在差异。比方互联网企业往往比较激进，轻易考虑一些自研、开源产品；金融企业则相对稳健，多从稳定安全角度考虑等。

3).用户属性
用户属性，可简单划分为C端、B端、G端，对应个人用户、企业用户、政府用户。个人用户需求，对架构灵活度、可扩展本事往往有较高要求；而企业客户则更为强调稳定服务、生态兼容等因素；政府客户则对数据安全、高可用方面有着更高的要求。

4).发展阶段
企业处于差别发展阶段，对架构的要求也差别。初创期的企业，往往看重架构快速构建本事，满足业务发展初期的多变性和时间性；快速增长期的企业，则看重架构扩展本事和演进发展本事；稳定期的企业，看重架构的稳定服务本事和TCO；而衰退期，看重架构的TCO和可裁剪性。

5).外部大环境
外部大环境，对整体经济面影响，也会影响到企业对于架构的选择。当经济下行的时候，更多的企业会考虑架构稳定和TCO，而非创新。

6).新增长点
在某新兴领域的增长点，对于架构往往会带来特殊的要求。这也是业务特点所导致的，需要有个技术逐步摸索的过程。比方物联网、直播、电商等都如此。会有非常鲜明的带有特殊背景的技术诉求。

下面从一个较为传统的企业客户视角，看看其表里部对数据库架构的核心需求是什么？这些因素都将对后续的架构设计，带来很大的影响。

1).外在需求
对于外在需求部分，可分为如下几个方面（有优先级顺序）

服务在数据库架构上，传统企业通常利用大型商业数据库多年，已经习惯于”交钥匙”的模式。非常看重其完备的服务本事，使得企业可以安心于业务。即使每年付出昂贵的服务费，但企业仍然可以接受。

生态在过去二三十年，国外大型商业数据库在中国取得不错的成绩，这不仅其自身功能很强大，其周边生态也颇为美满。这里不仅包括上下游的配套软件、工具，还包括成熟的架构、设计、开发、运维、测试全栈技术以及积聚多年基数很大的技术人才基础。

安可作为国家的政策要求，对于某些行业自主可控是必须要考虑的。这一点，无疑对国产厂商有很大的优势。但需要注意的是，对于开源软件的利用，企业也要注意评估风险。一方面是可能存在的法律风险（究竟开源协议比较繁杂）；另一方面是技术风险，对开源代码的理解把握也是需要企业很大投入的。

性价比作为商业行为，价格因素也是企业重点考虑的。这里需要关注两点：一是价格自己不仅包括一次性采购，还要盘算长期服务的问题；二是对于云服务，可能短期较少，但需要关注其长期费用。

2).内在需求
对于内在需求部分，可分为如下几个方面（有优先级顺序）

可靠性数据安全，是数据库的底线。保证数据准确、不丢失，是很多企业第一位去考虑的因素。

可用性持续可服务，SLA指标在一个较高的水平，也是企业的考察重点。特别是对于核心业务而言。

功能在功能上，应做到尽量完备。特别是对于已经习惯于大型商业数据库的用户。诸如视图、存储过程、支持复杂SQL等很多备受互联网摒弃的需求，对传统企业而言仍然是必选项。要全部适配改造，其代价往往是无法承担的。此外，对于一些新型功能，如多模、混合负载等，也是功能上的加分项。

扩展性数据库产品，应具备较为美满的盘算、存储的扩展本事，来应对企业可能遇到的业务发展或转型。如果在扩展性上有显式的瓶颈，也应提前告知用户。在整个扩展过程中，应做到尽量顺滑、风险可控。

易用性尽量降低用户的利用门槛，一个窍门是向大厂靠近，符合大多数人的传统习惯。这一点是很多国产厂商，需要重点增强的。

企业、部门、团队的环境，也会对架构选择有所影响。

1).公司因素
如之前环境篇开篇谈到的问题，公司所处行业、性质及发展阶段对架构选择存在差别影响，这里就不赘述了。

2).部门因素

部门定位部门定位如何？是否与公司业务强相关？是否有足够的架构主导权？这些都会影响架构选择。

管理者差别管理者，对架构的选型、落地起着重要作用。究竟架构的变更，需要泯灭大量资源，且存在一定技术风险。管理者的态度、做事方式、技术敏感度、所领导团队的执行力等，都会直接或间接影响架构的落地。很难想象一个抱残守缺的管理者，会支持推广一个激进的技术革新。

考核方式架构调整，意味着变化，可能有收益？可能有风险？这些对个人来说，会直接影响到其考核环境。一个相对宽松、容忍试错的环境，对于架构变更是更为合适的。

3).团队因素

发展阶段一个稳定的，受到公司认可的团队，对于架构的落地很重要。否则，接纳小步迭代、先边缘后核心的策略，将更为合适。

团队氛围团队的环境，包括配置、资源、氛围等，对架构也很重要。

个人角色个人在团队中的角色，能发挥出多大作用？如何从边缘角色中逐步脱颖而出，是值得考虑的。

TWO技术篇

数据库架构在近些年来正在发生一些变化。下面的技术篇中，将从企业利用数据库方式及对当前一些技术话题（开源、云、国产化）谈谈个人观点。

1).商业数据库 + 商业服务
这是较为传统的一种方式。企业购买大型商业数据库软件，并对应购买服务支持工作。在过去三、四十年里，这是主流方式。可以说也很好地满足了各类企业的快速发展。只是随着近二十年来，互联网化的厘革，对此种方式产生了不小的冲击。这种方式得当传统企业，对数据库要求较高，自有技术本事有限，未来发展相对固定的环境。未来发展随着商业数据库的发展而变化，从总体来看，未来云化的需求对其冲击较大。此外，在国产化、自主可控化等要求下，也会对这个模式影响较大。

风险分析

技术风险：技术封闭、不开放；不符合自主可控要求。
政治风险：如是外商产品，还易受到政治环境的影响。
财政风险：轻易受到厂商绑架，经济投入上不太可控。
人员风险：受厂商技术人员技术本事水平影响很大，自有人员无法承担，长期得不到发展。
功能风险：成熟商业产品，很难定制化满足客户个性需求；且存在与其他组件集成风险。
转型风险：接纳某商业产品后，想转型他产品较为困难。

本钱分析

人力本钱：从人力本钱角度来看，整体投入不大，重要是由厂商提供。自有人员重要是完成审核、评估等工作。
财政本钱：财政本钱是几个方案中，相对最高的一种。
时间本钱：对时间本钱而言，是相对较少的。选择商业数据库+服务，也就是看重其多年产品研发技术积聚和成熟的商业交付本事。无论是产品成熟度、稳定性；照旧服务支持方面等，一样寻常都是可在较短时间内交付的。

2).商业数据库 + 自主服务
这一方式也较为常见。在前一方式中，随着企业利用商业软件的深入，自有服务需求就变得急迫起来。通过建立自有服务体系，可以更好地满足企业自身需求。这种方式，得当有一定技术积聚的传统企业。未来发展随着商业数据库的发展而变化，总体相对稳定。

风险分析
在风险方面，与前者雷同。其中技术风险上，自有人员对商业产品的把控，较原厂照旧有所差距。固然对应人员风险就降低，通过自有人员对产品把控力更大。

本钱分析

人力本钱：人力本钱相较于前者有更多的投入。商业数据库产品推广多年，相关人才保有量很大，因此一样寻常很轻易雇用到需要的人才，且往往价格也不太高。这与后面的开源软件，形成鲜明的对比。
财政本钱：财政本钱来说，投入仍然相对较大，商业软件的采购费用占整体的大头。
时间本钱：从时间本钱看，较前者有所增加，但整体仍然偏少。这重要是由于商业数据库成熟的生态，很轻易搭建出运维体系；且人才方面，也较轻易去增补

3).开源数据库 + 商业服务
随着开源数据库的日益成熟，越来越多的企业开始利用开源数据库。但相较于商业数据库，开源方案对企业自有技术本事要求较高。因此，很多考虑搭上开源海潮的企业，接纳这种方式。适用于转型中的企业，从商业走向开源，这种方式可以在一定程度上规避风险。但一样寻常为过渡阶段，长期来看照旧要培养企业自有的服务本事。

风险分析

技术风险：开源数据库自身技术风险、企业技术选型风险及商业服务本事风险。
人员风险：受厂商技术人员技术本事水平影响很大，需要认真评估。
功能风险：一样寻常而言，开源数据库在功能上相较于商业数据库，照旧有所欠缺。因此这部分要仔细评估。

本钱分析

人力本钱：人力本钱来看，处于中等水平，相较于商业服务，其综合人力本钱有所降低的。
财政本钱：财政本钱投入大体中等左右，但服务厂商差别差异较大。
时间本钱：投入较少，但相较于商业方案，需要企业对商业服务做更多的技术考察。因此在初始的评测阶段，往往需要投入较多的时间。

4).开源数据库 + 自主服务
这是范例的“互联网”玩法，也是较为常见的一种方式。适用于规模较大，企业定制化要求较高的场景。发展成熟可考虑向企业内部私有云或数据库产品、方案方向发展，甚至对外赋能。

风险分析
风险分析与上者雷同，突出人员风险，需长期培养投入。

本钱分析

人力本钱：这种方式的人力本钱相对较高，但根据企业的利用规模、难度差异较大。开源数据库的发展也经历了一段时间，市场上人才保有量也逐步提升。但对于高端人才，仍然相对稀缺，人才本钱也较高。
财政本钱：重要也体现在人力本钱上。此外，对于基础设施上也需要有一定投入，甚至可能比商业方案投入更大。
时间本钱：相对较高，企业要建立成熟的开源数据库运维体系，是需要一定时间积聚。

5).开源定制数据库 + 商业服务
这是方案3的一种特殊环境。企业不是利用原生开源产品，而是利用第三方公司定制开源方案，可能是纯软件，也可能是软硬一体式。这类方式，会针对开源软件的不足，做定制化改进，满足企业级软件的需求。但这种方式一样寻常企业无法自己独立运维，需要借助第三方公司的商业支持。对数据库的企业级特性有较高要求，但原生开源数据库又无法满足的环境。对于短期内有去除商业数据库的需求场景，非常得当。随着国内对开源数据库利用水平不断深入，有越来越多的此类初创型企业出现。非常看好这种模式的未来发展。

风险分析

技术风险：定制化部分不开放，企业不可把控；此外，原生开源的版本变化，可能短期无法适用到方案中
人员风险：受厂商技术人员技术本事水平影响很大，需要认真评估。
转型风险：受限于方案，存在一定转型的风险。

本钱分析

人力本钱：重要来自于第三方服务，总体不高。
财政本钱：重要看方案环境，差异较大。
时间本钱：可视同纯商业方案。

6).私有云 + 云化服务
企业私有化部署方案，是一种云化折中方案。受限于一些特殊国情，有些企业无法直接利用公有云，但又急需雷同公有云的平台本事。因此，某些云厂商或数据库厂商提供了一种私有云化部署方案。可简单理解为将云搬回家。过去有种说法，说私有云会逐步萎缩，公有云会一统天下。但从近两年的国内云市场发展来看，私有云的发展速度某些指标甚至凌驾公有云。当我们现在大谈”toB”市场成为下一个蓝海时，这种模式也是toB服务市场的一个重要构成部分。这种方式，得当于大型企业，长期看好。

风险分析
其风险点除了在财力方面，更多是考虑在对厂商的技术依靠性。相较于传统方案，这种方式的依靠性甚至更高。厂商一样寻常提供很好的私有云，及对应其自有公有云的买通方案；但对其他公有云或企业自有平台，则较难买通。

本钱分析

人力本钱：投入不大，重要取决于厂商人员投入。
财政本钱：虽然相较于大型商业解决方案，有一定的本钱优势，但优势不甚显着。
时间本钱：要长于传统方案，究竟这不是单一技术平台的更换，而是涉及到Iaas、Paas等诸多层面。

7).裸云 + 开源数据库 + 自主服务
这是一种上云利用的初级阶段，企业仅利用云的Iaas部分，其余均自建。这种方式可充分利用公有云带来的弹性优势，将企业原有的技术积聚延续到云端。对于企业来说，这种方式也是最为“平滑”的，甚至应用可以不做更多感知，仍然像利用企业内部IT资源一样，利用公有云资源。很得当于有多云、跨云需求的场合。但缺点是无法利用云厂商技术本事带来的附加值。

风险分析
风险不大，仅仅是依靠公有云底层，很轻易迁徙到其他云厂商或迁回自有。

本钱分析

人力本钱：较之前自主运维，有些差异但相差不大。重要是底层IaaS层人员会有些职能变化。
财政本钱：从本钱角度来看，企业可做到”最优”。仅利用裸机的环境下，完全可以按”价低者得”的策略，优化选择。在一定规模环境下，公有云照旧有其价格优势，况且还可以充分利用弹性本事，动态缩减，根据企业发展随时调整IT投入。人员方面，与企业自主运维变化不大。
时间本钱：由于底层交付速度的提升，照旧有一定的提高。

8).裸云 + 商业数据库 + 第三方服务/自主服务
这是一种较为特殊的环境。企业选择将商业数据库，构建在公有云上。但其没有选择云厂商提供的，而是自主构建或选择第三方厂商协助完成。这往往是一些中小型的企业，其规模不足以支持私有化部署，而应用又依靠于商业数据库产品。企业想要充分利用云的弹性，因此组合出这种利用方式。

风险分析
风险在于，某些商业数据库针对云场景的不予支持，企业有一定技术风险。要么有比较强大的自主技术本事，要么依靠于第三方服务厂商。

本钱分析

财政本钱：重要是针对基础设施层面，会较自建有所节省。
人力本钱：差异不大。
时间本钱：差异不大。

9).云数据库（开源） + 云平台服务
这是云厂商推出的最为“传统”的数据库服务，也是目前最多的一种选择。云厂商基于开源的数据库版本+自有的平台服务，构建其数据库产品。其核心的数据库与开源的版本，是完全一致的，各家比拼的更多是平台服务本事。这种方式对于企业的运维要求很低，根本可以依靠于云厂商提供的本事（除了个别高可用、容灾需求外）。这一方案比较得当于初期上云企业，可逐步摸索云与原有方式的区别。

风险分析
数据库自身风险不大，究竟其利用的与开源同一版本，技术上可迁徙至其他云厂商。当数据库版本升级后，也可以享受到对应的技术红利。但对平台服务，是存在一定依靠的，各家本事差别，需要有适应过程。此外，运维依靠云厂商，也存在一定技术风险。自主的技术本事，会逐步丧失。

本钱分析

财政本钱：与商业方案比较无疑是有优势的，但与自主开源对比，险些没有优势。其更多的是在快速交付、扩缩容等方面产品特点。
人力本钱：因运维类工作大幅度降低，因此是可以节省一定人力，压缩自有人员规模。
时间本钱：有所提升。

10).云数据库（开源定制） + 云平台服务
云厂商除了提供与开源一致版本外，一样寻常还提供私有定制版本。它往往是基于某开源数据库某一版本的深度定制，针对某些特性做了增强。固然有些以反馈社区的方式，回馈给开源（可能未来会merge入新版），但很多仅存在在”云私有D”。如企业有针对某一特殊场景（如秒杀）或其他方面（如金融级数据同步）的强需求，可考虑利用此方案。固然利用也意味着与云厂商深度绑定。此外，在平台服务方面，与上面环境雷同。这种方案比较得当于对数据库有一定要求，而原生开源版本又不支持的环境。

风险分析
风险在于绑定单一厂商，一样寻常很难下来。这与利用大型商业数据库的环境雷同。固然可以在应用端做个设计，尽量减少对特性的依靠。此外，由于是定制版本，未来开源版本的升级可能不会短时间内支持，甚至可能不会考虑支持，完全走向独立分支的道路。针对这点，企业也是需要关注的。

本钱分析
与上一种环境雷同

11).云原生数据库（自研） + 云平台服务
某些大的云厂商，除了上述两种外，可通过自研数据库方式，增加未来的产品竞争力。从最新的Gatner报告来看，更多的云厂商加入进来，这也给数据库整体市场带来了活力。从预测来看，均一致看好云原生数据库的未来发展。相较于前两种方式，这类数据库更是诞生于云，从设计之初就更多考虑了云化环境特点，因此极具竞争力。固然，从目前来看，现有云原生还处于”初级”阶段，未来在解决了更大规模扩展性、多读多写本事等后，其将真正进入井喷式发展。现有各大厂，在这一领域纷纷重点结构，加大投入。对企业而言，无疑又多了一种选择，特别是某些场景（如海量数据等），原生开源、扩睁开源产品均无法满足。

风险分析
风险雷同上面，甚至有过之。企业应用将完全依靠于厂商产品。只管很多是宣传兼容开源或商业数据库，但究竟不是同一产品。这点还需要企业仔细评估。此外，针对兼容性、备份恢复、高可用、数据同步、跨云容灾等，都是值得投入研究的。

本钱分析

财政本钱：目前各厂商都在不遗余力地推广，因此从本钱上企业照旧可以受益的；但从长期来看，还需要进一步观察。
人力本钱：从人员来说，企业也是需要一定投入，究竟这是一种全新的数据库，虽然云厂商提供了很好的交互平台，但照旧需要企业做一定的技术储备，因此人员上还需要些投入。
时间本钱：时间上来看，对于这个比较新的产品，还需要做更多的测试评估工作，因此也是需要多些投入。

12).云数据库（自研） + 云服务 + 云托管平台
这是一类小众的方案，其背景是缘起于数据库厂商与云厂商的蛋糕划分问题。有些数据库厂商（如MongoDB）不盼望将云数据库市场由云厂商主导，而是盼望可由自身主导，构建不依靠于云厂商的独立生态。目前这种方式国内见得不多。

受到众多互联网公司的影响，很多传统企业对于开源方案也是跃跃欲试。但在选择之前，也要看到，开源方案并不是免费的“蛋糕”。让我们来看看，开源方案的利与弊。

1). “利”的方面

价格这往往是企业，最先看到的一点。开源软件，可节省大量的商业采购费用。固然，我们这里要算一笔综合的经济账：

价格 = 采购 + 维护 + 人员 + 时间 + 机会

简单、灵活相较于商业产品，开源产品往往比较简单、配置灵活、不依靠于特有硬件等。在满足企业的技术要求下，这些确实是开源的优势。

可定制开源的一大特点，就是源码公开，企业可以根据自身特点进行有针对性的改造。对于企业的某些特殊要求，确实只能通过定制化才能完成。

人才+技术随着近些年来对开源软件的利用，开源的人才已相对较多，企业可以较为轻易地雇用到人才。且企业大规模利用开源，也可逐步提升企业自主技术水平，有利于企业的长期发展。

2). “弊”的方面

服务服务，特别是规模化后的服务。开源方案，一样寻常重点着力于核心功能，其周边功能往往比较薄弱，这对于后期服务很不利。通常企业是依靠自身的人员完成服务。这通常需要一定的投入，且整体服务质量较成熟的商业产品仍有较大差距。这一问题，可通过“开源软件+商业服务”的模式，大概通过云服务来提升整体服务水平。

产品责任这就是所谓的“兜底”问题。国内的企业，往往已经习惯于有外部厂商资助其兜底，尽量规避自身风险。利用开源，难以找到指定的责任方，兜底更无从谈起。虽然可依靠某些第三方服务商，但其对开源的掌控本事需要评估。

运维复杂度成熟商业产品，通常颠末完备的设计开发、丰富的周边生态、系统的文档化及多年的磨炼积聚，其运维复杂度较低，可快速搭建起美满的运维体系。但对于开源而言，需要从头来做，自己独立完成整个过程。

技术演进路线开源技术的发展，通常没有固定的主导方。企业很难把控，开源软件未来的发展方向。某些企业急需的特性或bug fix，也很难得到及时的响应。企业整体是缺乏把控力的。

性能开源软件，在一样寻常简单场景下，其性能不差，甚至好于很多商业产品。但从整体综合性能来看，特别是在复杂场景下，其性能往往体现不佳。因此，针对开源方案，往往强调前期架构设计很重要，发挥其强点、规避弱点。但这对于传统企业尤为困难，企业有很多沉重的历史包袱，很难短时间内完全重构。即使决定重构，也需要逐步摸索，小步迭代。

用户体验开源软件的第一诉求，是功能的实现，其针对用户体验往往考虑不多。利用惯商业产品的用户，需要一个“由奢入俭”的适应过程。

企业级特性企业用户，对数据库的利用是有其专有特性，比方：安全审核、数据加密等等。这类功能对于企业很重要，但对其他类用户相对意义不大。很多开源软件，不会在这些上大做功夫。

1).云DB与传统DB的差异
核心功能
对于托管类数据库产品而言，其核心功能照旧要跟官方产品走。固然，各个大厂都有着自己多年丰富的实践履历，并具备一定的内核研发本事。于是，往往针对原生产品做一些定制化的改造，进而提供与原生产品差异化的本事。改造方向上，往往倾向于下面几类：

性能。深度优化后的产品，往往较原生性能有较大的提升。这也变相为用户提高了综合性价比。
功能。针对原生产品功能不足，增强其功能。特别是对于有些企业级功能，更为需要优先满足。这也成为很多线下客户，选择云数据库产品的重要考量因素。
业务。有些大厂根据自己在某业务领域的积聚，有针对性地增加了特定场景下的数据库端解决方案。这对于同行业客户来说，非常具有吸引力。

针对上述定制化后产品，偶然就成为某种“银弹”，对于企业客户很具吸引力；但事变也具有两面性，对于这些特殊之处的依靠，也会导致客户对产品的依靠。这也是某些客户犹豫之处。在我看来，这个问题的要点在于企业处于的发展阶段。差别阶段的企业，核心诉求差别，在此处的考虑角度也会差别。

外围功能
除了核心功能外，还有些非数据库核心本事，但对于企业利用必不可少的功能。比方：监控、备份恢复、优化、容灾等等。如果没有云的话，这些本事往往是需要企业泯灭精力去自建的。哪怕企业数据库规模不大、利用复杂度不高，利用开源数据库也能满足需求，但上述需求照旧要满足的。于是，前两年平台热很火，很多企业都自建了自己的内部运维平台，构建上述本事。固然这种方式有利有弊。利之处在于，企业可以根据自身需求度身定制，满足个性化需求；弊之处在于，构建本事及泯灭资源长期维护。

云功能
如果说，上述功能企业照旧可以较轻易具备的，那么云功能则相对门槛有些高了。这里所说的”云功能”，是指比方弹性扩缩容等类。这类本事，往往需要依托于强大的底座本事，是需要较大的研发投入和长期积聚才能具备。在某些特定的场合下，这一本事对企业很具吸引力，比方业务形态、幅度变化很大的企业客户。

生态功能
企业选择上云，往往不是仅依靠一两款产品，而更多是看中云端生态功能。对于企业来讲，如何通过云端买通技术瓶颈，快速具备业务本事成为核心。比方从数据埋点、数据捕捉、数据存储、数据盘算到分析展示，如果全流程都可以在云端无缝集成，对于企业来说，是很具有吸引力的。

2).如何看待上云本钱
从人力、财力、时间、风险四个维度分析其本钱问题。

人力本钱无疑，这是云数据库颇具优势的方案。企业如果想通过自建方式解决雷同问题，没有高素质的人才是不行的。然而，一方面此类人才稀缺且价格不菲；另一方面即使已有人才，也要面临如何留住等问题。究竟对于大多数企业来说，专业技术人员更多是辅助性岗位，对高级专业人员来说也面临长期发展等问题。而云数据库方案，则不存在此问题，你大可以在很短时间内享受到大厂的“脑力”资源，而且不必担心出现断档等问题。

财力本钱针对这点，是需要企业充分衡量的。如果通过自建方式，是初期投入大，中长期投入较少，存在一个显着的波动性。如果通过外购云服务方式，则相对较为均匀。两者的财力分配方式差别。固然，云有一个显着的优势，就是弹性。企业可根据自身环境，灵活选择，随时调整。

时间本钱这是企业往往轻易忽略的问题，时间投入也是一种本钱。当你的企业快速发展，需要短时间具备某种本事；当你面临新业务上线，而后台IT就迟迟跟不上节奏。隐形的时间本钱，偶然对企业颇为重要；对稍纵即逝的业务机会来说，稳健、灵敏的IT支撑本事很重要。

风险本钱很多企业是需要一个”兜底”的服务，即尽量降低企业的IT风险，保证企业的正常运营。自建的方式可以解决，但需要构建起整套的本事，投入不小；也可以通过购买外部服务的方式，这种就需要考察对方的技术实力、并解决互相扯皮等问题。云厂商，则不存在此问题，根本可做到风险可控。

1). 产品技术成熟
作为三大核心基础软件之一，数据库在整个IT技术中占据重要的位置。随着近些年来中国经济的快速发展，特别是巨大的生齿基数带来的红利效应，互联网技术在中国发达发展。甚至在某些技术场景下，相较于国外有着更高的要求。这也促进国内企业在IT基础技术（包括数据库）上取得了长足的进步。国内企业对数据库的利用大抵走过了“商业->开源->开源+定制->自研”逐步演进的道路。近些年来，随着技术、资源、人才的积聚，国内的数据库领域取得很大的突破。从数据库技术自己而言，随着分布式、云原生软硬一体化、人工智能等技术的出现，为自研数据库代替大型传统商业数据库，实现弯道超车提供了可能。同时这些技术的出现，也解决了很多传统数据库固有的问题，突破了旧有架构的缺陷，更好地满足客户对海量、弹性、安全、性能等方面的要求。没有传统数据库厂商的历史包袱，新兴厂商站在更高的起点上，实现对传统厂商的超越。

2). 履历积聚丰富
虽然有些企业在去除大型商业数据库实践上，已经有十余年的时间；但大多数都是限于企业内部。受限于其内部场景，很多实践履历是很难复用到外部企业。且也没有一个完备、成熟的商业化产品提供此类服务。但是近些年来，已可以显着看到一些变化，以云厂商为代表，正在将企业内部多年的履历积聚以产品的化的方式输出，资助广大客户完成这一过程。针对这样一个基础软件的更换，我们需要苏醒地熟悉到，不是简单的“苹果换成桔子”的过程。这需要从架构设计、步伐开发、运维安全等多个角度去看待。之前很多企业在抛弃传统商业数据库上举步维艰，正是由于缺乏必要的履历指导，无法将好的技术快速落地并稳定运行。在这里需要重点强调的是，很多企业以为选择一个功能非常强大的数据库，就可以帮着自己摆脱传统商业数据库。其实，这是一个大大的误区。功能强大的产品，不一定是得当你，要想完成这一过程，云数据库厂商的实施履历不可或缺。只有“好的产品+丰富履历+良好服务”，才能最终达成这一目标。

3). 服务方式提升
企业（特别是传统企业）在数据库利用上，按需求的优先级排序，可分为服务、生态、自主、本钱等多个因素。这里最被企业看中的，正是“服务”一环。很多企业利用大型商业数据库多年，已经习惯于传统数据库厂商的“交钥匙”工程，非常看重其完备的服务本事，使得企业可以安心于业务。即使每年付出昂贵的服务费，企业仍然可以接受。这点也是国内厂商的短板，要在短时间内建立其等同于国外数十年积聚的企业服务本事，不是一朝一夕的功夫。这是需要国内厂商静下心来，苦练内功，加大投入。颠末几年来的积聚，国内的云厂商已具备了较为成熟交付服务提醒，形成了规范化的服务本事。

4). 本钱收益驱动
传统大型商业数据库，颇令人诟病的一点就是“贵”。究其根本缘故原由，一方面是其商业策略有关，此外也有人力本钱、服务方式等因素有关。此外，还有很轻易忽略的一点，就是旧有架构的问题。随着新架构的演进、技术的突破，特别是“数据库+云”的结合，为客户提供更灵活、更具性价比的数据库方案成为可能。

5). 业务模式创新
随着数字经济的到来，各类企业都在做着数字化转型，新的业态也不断涌现。这对于支撑企业数字化转型的重要基础设施—数据库，提出了更高的要求。如何满足快速多变的业务模式创新？如何满足快速发展的业务规模需求？等等诸如此类的问题，都是数据库产品需要考虑的。国产数据库正是站在这一高点，从国内环境出发，有针对性地推出很多功能，满足这种创新。

THREE实践篇

下面以笔者之前在某公司的实践过程，谈谈对架构实践的理解。这里将从需求、资源、路径、发展角度来谈。

第一步，就是现状分析。俗话说，磨刀不误砍柴工，只有对现状充分的了解，找出核心痛点，才能有助于问题的解决。无论是从架构调整照旧其他工作都是如此，只有解决痛点才是对公司有价值的。

第二步，就是路径演进。很多架构工作或其他技术工作，都不是一蹴而就的，而是有个逐步演进的过程。正如上面提到的，在之前公司的数据库开发设计规范的落地，也是走过了文档化->技术宣讲->自研平台的过程。

团队的环境也很重要。只有统一思想、明白方向，才能有助于最终落地起效。

FOUR发展篇

最后，我们谈谈对架构师作为个人发展方向的一些问题。信赖很多做技术的同砚都存在上述的问题？做技术照旧做管理？年龄因素怎么看？技术革新太快，如何破？等等

首先我们从企业内部数据应用条理来看，从最为原始的满足事务型处理需求，DBA更多是充当救火队员的角色；到逐步规模化、体系化，DBA通过平台处理运维工作甚至可做到预防性运维；再到运维工作已不是重要矛盾，企业开始关注数据库设计、开发质量问题，DBA需要更多考虑架构侧问题；最终到脱离具体库的形态，而从更高维的数据层面考虑企业内的数据架构问题。企业内部对数据的应用条理的演进，其实也是DBA从运维、平台、设计、优化、架构的演进过程。可以说，伴随着企业发展，数据一线从业者都会慢慢具备一定的架构类职能。这也是技术人，比较理想的一个发展路线。

从一段时间来看，DBA职业正受到很大的冲击，这里包括：

去IOE所代表的去商业数据库冲击，仅仅把握一两门商业数据库技能已经不足以支撑你的职业发展。
开源与商业的选择，决定了越来越多的开源方案受到重视，DBA的技能不在满足于对商业产品的诉求，而是要考虑开源及随之带来的研发类的技能要求。
管理方式的变化，从之前的手工下令方式、到脚本进而到工具乃至平台。管理方式的变化，也意味着对DBA技能的不断提高。
云，作为未来发展趋势，已成为共识。在云化环境下，对DBA的本事要求又有了新的变化，很多之前的技能将变得不在重要，急需要人员把握新的技能。

这是个老生常谈的问题，做技术照旧做管理？我的观点是，选择哪条路径，取决于个人特质，差别的思维方式得当做差别的工作。不要勉强自己做不得当的职业选择。

技术的路能走多长？这是很多人的疑问。岂非每个人都能发展成为CTO吗？显然这是不现实的。无论是技术路线照旧管理路线，其发展都是有阶段性的。对于迈入到更高的台阶，都存在一定比例的选择率。大部分人，是无法上升到更高的阶段，要理性地看待这一问题。并在到达自己阶段瓶颈后，找出后续的发展路线。说句时髦的话，就是所谓第二发展曲线。

承接上面，每个人发展都是存在一个阶段性上限。当到达这一阶段时，你会发现很难突破自己，此时可以考虑所谓T字性人才发展策略，即横向发展。但这里需要注意的是，一定是在某一领域内靠近自己所能到达上限，由于这会决定你的“视野”问题。在横向发展的选择上，可以有很多。比方右面列出的技术上的其他领域、业务方向的沉淀大概加入人的工作（管理）之中。

文章泉源：DBAplus社群

作者: 业春林 时间: 2020-11-4 17:47
转发了

作者: 羽林润之 时间: 2020-11-5 06:12
不错

作者: IT杨 时间: 2020-11-5 07:03
转发了

作者: qhs8848 时间: 2020-11-6 19:14
转发了

欢迎光临创意电子 (https://wxcydz.cc/)