孔令俊
作者孔令俊2019-07-02 18:16
软件开发工程师, 建行

分布式模式下给企业带来岗位职责变化

字数 7096阅读 12546评论 1赞 3

前言

本文不讲究文笔 , 不讲概念 , 只是根据自身的一些经验 , 对分布式下的职责变化和大家进行探讨 , 由于自身能力的局限性 , 可能存在错别字 , 或者错误的观点 , 请有识之士明辨是非。

分布式

什么是分布式?一个企业两套系统是否可以看作一个分布式部署?一套系统两个数据库、计算和存储分离、一个数据库部署在多个物理机是否可视为分布式部署?这里我们不纠结于场景或者实现形式的差异 , 从本质上看问题。

分布式对应的就是集中式 , 分布式和集中式最大的区别:

1.集中式就是一个环节做了所有的事情 , 对外体现成一个整体或黑盒子 , 用户不用考虑其内部实现 , 只要通过标准接口访问就好 。个人认为主机就是一个很好的例子 , 主机内部也有很多分布式设计 , 但是都是内部控制 。对外提供统一的访问接口,因此主机对我们就是集中式部署 , 通常大家也这么理解。

2.分布式就是一个工作要通过多个环节来完成,设计者要考虑每个环节的建设,多个环节之间的交互,环节之间的切换,每个环节部署内容的考虑。按照这种概念,我在想 CPU 指令执行的流水线设计,是否可以作为一个分布式的代表,因为 CPU 设计过程中将简单的取指令动作分解成好多环节。

从两者区分,我们可以看出,分布式建设比集中式复杂很多,因为集中式把可能出现的问题都内部解决,不需要外部干预太多,但分布式是将集中式的内部环节分解,暴露出更多的接口,使架构更灵活,选择能力更强,但付出代价是需要所有环节有效协同才能保障整体的可靠、可用。集中式依赖于产品自身的稳定和能力强弱,较少选择项,分布式很大程度依赖设计规划和接口开放能力,从而具备较多地选择项和建设方式。

传统的岗位规划


这个组织架构是大多数企业的架构模型,我们就从分布式对传统的岗位带来的挑战和变化,来分析未来分布式架构下的岗位职责变化和处理问题方式。

分布式对岗位职责的影响

业务

业务决策

1、 变则通,通则达

决策人员必须能够清晰判断分布式下的一些技术限制对业务的影响,及时的调整业务目标或者实现阶段。一个业务的开始,首先要提出的就是业务目标,在传统的模式下,业务目标往往以功能为主,要高大上,不能有瑕疵。但是在分布式体系下,由于其特点和技术上的约束,要有对技术的包容性和对目标的变通性,例如分布式架构下数据的差异性,统计数据的非实时性等。追求业务目标的完美往往是分布式规划夭折的原因,退一步海阔天空,残缺也是一种美。

两个重点变化 :
认可最终的一致性
分布式模式下模式下,重视业务的并发能力,不一味追求单笔的时效

2、 顾全局,识大体

分布式会导致业务流转环节增加,要求业务决策者不能只看到入口或者出口,要能对实现全局过程中的每个环节进行决策和规划,并且能够保证局部和整体的方向性。缺乏中间环节的决策和对全局的掌控是建设分布式过程中常常面临的难题,因此要对一些关键问题进行必要的架构决策,总之两手都要抓。

流程规划

1、 有效分析业务流程,去长补短,降低热点

业务中通常即包含面向客户的服务流程,还有面向管理的管控流程,相互交织。管理流程往往涉及众多客户,容易形成热点流程和性能瓶颈,这也是为啥集中模式下效率低下的原因,一个热点的流程制约了整体的服务能力,因此对热点服务要进行合理部署,可以采用冷热分离的松耦合模式,避免冷热相互制约。例如经典的交易和核算分离;

执行时间长的模块很容易产生热点,所以要有流水线设计思路,把长服务拆成短的。

为了避免热点。有时也要根据需求,适当的增加热点服务的流程环节,降低热点的效应,本质还是流水线越长,选择性就越多,越可以并行。

我们这里用快递行业进行举例,通过增加流程环节,增加分发服务,降低快递人员的服务范围,提升对客户的服务能力,正是磨刀不误砍柴工,并不是流程短就最好。通过对短流程的分层划分,虽然分层服务导致一定的汇总或者分发开销,但是提升了服务的分布式能力。

实际的应用场景就拿汇总统计类业务为例,如果所有汇总都实时面向一个点,这个点就是热点,但是在汇总过程中,增加一些缓冲环节,然后再通过对缓冲进行汇总,即可以保证局部服务的一致性,又可以保证服务的扩展性。

2、 兼顾开发和部署,力求服务的原子化设计和运维的可扩展部署

业务是由千万个服务组成,从开发的角度 , 希望服务的共性越强越好,这样便于服务复用,简化开发但这也容易产生热点;从运维的角度,强调服务的扩展性,差异性,能够通过服务的多实例部署提升性能,服务之间尽量松耦合,降低单个环节对业务整体的影响。这里就需要业务的设计要更灵活,我们就用一个最简单的例子来说明。

凭证在大部分业务范畴都普遍使用,不论是电子的还是实物,但是往往有一个先后次序的流程要求,导致选择可用凭证要从某个集中的地方找到下一张可用的凭证号,人为造成了热点,虽然开发很简单, ”select min(No) from table for update“, 但是运行的效果就很差,凭证的有序使用是实物凭证遗留下来的传统,因为可以方便实物的管理,否则万千凭证找一张,困难重重,但在分布式的模式下,已经成为制约业务分布的枷锁,如果去掉顺序,则可以采用分片预留的形式,降低热点,互联网业务为啥可以普遍的采用分布式,很大的原因是没有机构分级,没有实物的困扰,电子化普及很高。通常银行等企业中往往面临金额控制,现金帐务管控,流水号等都附加要求,制约了分布式的部署。

所以在流程设计中几个关键因素:

  • 去实物分配,普及电子化,降低管理成本
  • 关注热点数据,按业务需求提前部署分配
  • 降低实时要求,扩大异步处理和并行处理。

架构

数据职责

1、 保证数据访问入口低维

数据的合理设计是有效分布的基础,简单例子,如果一个客户可以通过电话、身份证、姓名等访问,如何分布才合理,结果就是很难,虽然可以通过补偿方法就是选择某种纬度进行分布,再增加一个外部索引,将多维访问影射成单维访问,但还要解决外部索引数据的分布和性能。因此在数据模型建立初期,就要严控数据的访问纬度,虽然多维访问能方便客户服务,但是一个统一的身份证纬度更利于分布式部署和设计。

2、 客户数据和管理数据的分离

实际的业务中,很多数据包含了管理的信息,例如办理人员,办理机构,结果就产生了对数据多维访问需求,所谓鱼和熊掌不能兼得,要根据业务目标,合理的进行数据分离,例如可以考虑如下分离方式:

  • 为了管理方便,以管理的纬度分布数据,例如省份,机构,业务类型
  • 为了交易的离散,以客户的纬度分布数据,例如客户号,身份证等
  • 各自为政,客户数据和管理数据分离,不同的客户数据分离,不同的管理数据分离。

集中模式下所有数据放一起是目前普遍的模式,这也是开发很难进行业务分布式改造的原因。

事情都具备双面性,分离的结果产生了数据的冗余及复制需求,要考虑通过异步或者集中处理,降低分离造成的影响。

3、 虚虚实实,分分合合

分布式不是简单的数据拆分,伴随而来的就是效率和一致性、还有性能问题,因此对在数据模型的设计中,根据数据的访问特性,考虑能否建设副本,或者在其他数据里进行冗余,考虑各自的优势:

  • 单数据容易产生热点,但能保证一致性
  • 多个副本容易产生不一致,但能提升可扩展性,消除热点
  • 副本和某些实体数据合并部署,提升交互效率。

在设计虚实数据实,要考虑子集范围,同步方式,同步内容,毕竟数据项的变更频率并不一致,简单的全数据复制背后是资源的浪费。

4、 扩展数据属性,全局概念统一

由于数据的分布和众多副本的产生,对于数据的定义不能只局限于功能,还要补充因为分布而产生的其他属性,例如主、从,主要、次要,差异间隔等,从而在后续组织流程中,可以有选择的访问。

业务架构

1、 业务模型、服务粒度规划

SOA ,微服务要求功能的离散,松耦合,合理的服务设计是关键,往往是业务架构的分布要求驱动了数据的分布部署,虽然大神都膜拜自底向上的方法论,但也要避免空中楼阁。

2、 兼顾联机和批量

分布式能提升联机的扩展,但给批量带来挑战,过度分布带来的批量复杂度可能是开发很难实现的,对业务的分布和集中处理要有合理定位。分布式体系下,往往形成了专门的数据线,通过数据的汇总和分发来解决分布式下批量的复杂,就是用空间和时间来解决批量的复杂性。

3、 交易核算设计

交易、核算的分布模式是目前企业做分布式最容易入手的途径,反之如果交易核算都没分离,后续交易的分布建设将难上加难。

技术架构

1、 分布式下多中心部署模式

分布必然带来多活,主备等模式选择,合理的部署模式能更有效的支撑业务,合理的中心规划能更利于技术的发挥。但实际情况往往是屁股决定脑袋,领导一拍板就把中心距离拉远到 1500 公里,还提出同步的要求,给技术和开发增加了难度。

2、 分布式技术选择

分布式技术第一个面临的难题就是分布式数据库的选择 , 啥叫分布式数据库 , 我也不知道 , 这个问题应该交由各位需求者来回答 。到底要实现那些方面的分布 ? 目的是什么 ?

没有一个产品能适应所有的场景 , 因此在选择技术的同时 , 要考虑自身业务的具体情况 .

此外分布式带来数据的同步,是采用硬件、数据库、还是应用实现,能力指标是多少,知己知彼,不能为了分布而分布。

对分布式数据库我有个简单的技术区分途径 , 就是锁 . 锁的不同位置和实现方式的不同决定了这个数据库适应的场景的不同。 有机会我们仔细探讨锁位置和实现方式的不同对于业务的影响 .

3、 业务连续性的设计

分布式下单个分布节点的故障影响范围降低,但是故障频率和切换点确增加了,因此故障隔离、恢复手段和时间控制要更自动化。

灾备也是连续性的一个分支 , 只不过是距离远的连续性考虑。

### 安全架构

1、 分区设计

分区导致交互点增加,本来内部交互变成外部接口,合理的规划安全边界才能进行有效的安全管控。

2、 安全实现及策略

分区之间的认证、传输、访问权限等,都需要安全提前规划,而且涉及到多中心、多活的部署,对安全的要求也更高,安全在自身分布式建设过程也是一个很复杂的过程。

技术前瞻

1、 技术能力和方向 , 生态

目前分布式技术的发展还处于初期,因此对分布式现有技术特点要有清晰的认识,知己知彼才能百战不殆,不能幻想依靠某个产品就实现分布式,要充分理解分布式环境下对于生态中的多边要求。

很多人简单的理解分布式就是采用个分布式数据库。

2、 新产品调研及应用场景

分布式产品层出不穷,技术的变革带来新的设计,及时调研产品能力,才能快速进行应用适配。例如新的数据库多副本技术 (Raft,Paxos 协议 ) 就对传统的数据库复制技术提出挑战。

3、 自主可控

这是一个永远的话题,能进能退才是王道,技术的选择也是如此。

开发

框架

基础功能

1、 日志

分布式下如何将多个流程日志串联到一起,日志信息的内容要更丰富

2、 数据库

分布式下,数据的部署将更动态,数据库将变成抽象资源,传统的 IP 映射方式显然不能满足数据动态分布的要求 , 要具备服务和数据库的映射能力,数据库也转变成一种服务。

分布式事务

分布式下,一定要有框架的支持,才能提升开发效率,保证交易的一致性的。 目前很多分布式框架的方向,交易级别的,数据库级别的,采用两阶段协议的,或者采用数据库附加字段的,所谓乱花渐欲迷人眼,选择不同,结果不同。

调用传输

1、 同步、异步的能力

分布式下,异步更利于实现并发,能够有效提升整体性能,串行调用是分布式的敌人。

2、 多协议支持的能力

产品的差异,场地的不同,安全的不同要求,就要求协议的支持更广泛。

流程设计

流程引擎

流程引擎是分布式环境下的核心环节,更多的流程环节需要更并发的引擎支撑能力,因此对引擎自身的扩展性也带来很高的要求,很多情况下,流程引擎也要求是分布式架构,高扩展能力,否则就成为一个瓶颈。

接口设计

交互接口的标准化要求更高 , 可复用性更强,分布式下如果还要进行大量的报文转换,将是一个灾难

服务管理

服务治理要求能自注册 , 自发现 , 自维护,可以想象一个没有服务管理的分布式环境在产生变动时的手忙脚乱的景象。

模块开发

要求应用主动发起分布式调用 , 因此对数据分布要有一定的了解,并且为了性能提升,有可能要求开发者在实现过程中主动明确交易的分布属性,降低框架的解析时间。

运维职责

基础设施

硬件

1、 计算

计算节点慢慢从高端变向低端,从主机、 IBM 、 HP 变向 X86, 从产品使用延伸到产品设计,特别是分布式下规模扩大后,定制的硬件配置更是未来方向,硬件管理员的职责更具挑战性。设备维护从更换部件发展成更换整个设备,甚至出现了机器人更换设备的模式,这也对机房环境,电源、设备背板等提出更高的要求。

总体上计算的工作在分布式从动手慢慢变成动脑,从带厂商进机房变成自己去搬机器,从一月坏一台到一晚上坏好多台,不用考虑为啥坏,只要知道换完设备如何接网线就好。

2、 存储

存储在分布式下产生了翻天服务的变化,本地盘正在成为一种潮流,存储管理员从维护外部存储设备稳定、空间划分,转换到维护分布式存储系统的稳定,因此要求从技术层面熟练掌握分布式存储系统,能够自主的进行故障定位和分析。

顺便说一句,随着本地盘的使用,传统的存储的一些附加功能正慢慢被淡忘或被替代,例如存储复制等,我自己也在思考传统存储厂商未来的方向在哪里,同时有一个疑问,一个多存储机头,带上千个物理盘的磁盘柜组成的集中存储对比 一个由 100 个带 10 个本地盘的 PC 组成的分布式存储,到底哪个好?真的啥都可以软件定义,硬件链路没市场?

3、 网络

传统模式下一般注重南北向的数据的纵向交互,分布式下东西横向的流量可能更大,因此一个合理的网络架构是建设分布式环境的基础,因为分布式模式下,多副本是一个基本要求,大量的数据复制对网络的稳定和带宽提出更高的要求。

这里希望大家不要迷信 TCP/IP ,认为 IPSAN 就比 FCSAN 好,实际结果是谁用谁知道,便宜一般没好货,很多情况下是因为走得人多了才有了路,但不一定是最近的,只是因为好走。

软件

1、 系统

分布式环境下,容器,虚拟化的利用,要求系统管理员的知识面更宽

2、 数据库

分布式环境下,性能提升已经不是简单靠优化索引,加快统计更新能解决了,数据库管理员的职责从数据库性能优化转变向数据的合理分布,能对现有的数据分布提出合理的建议,根据规则及时提出数据拆分部署建议。

3、 中间件

中间件已经不简单是 Tuxedo,Weblogic,Mq, 更复杂的分布式消息,分布式文件传输等,需要更多的知识储备 , 更合理的部署设计。

应用维护

分布式模式下,已经没有传统的应用概念,有的都是模块,因为应用是通过多个模块的服务调用来实现的。 在这种模式下,一个模块的维护往往影响大片的业务,随着不断的系统上线,靠人来梳理模块影响已经不现实了。

所以分布式下应用维护人员对开发的要求往往是灰度发布,任何变更都要能在生产环境规划出一个灰度环境。

平台工具

资源供给

分布式资源的动态分配,对资源供给自动化能力提出很高的要求,所以一个能自动资源分配的云平台是分布式的基础。

应用部署

如果说资源还可以一次供给,永久使用,但是很少有应用全生命周期只有一次变更,实际情况就是可能每天都在进行版本维护,不要想手工操作了。这里要给开发提出更高的要求,在任何部署环节,不论是上线、变更、扩展等,都要随带相应的脚本,便于部署平台的调用和分发,这里面隐藏了一个应用部署的无状态性要求 , 啥叫应用无状态,就是所有应用部署可以用一个脚本完成,不会因为地域,设备容量, IP 等进行个性编写。

故障切换

如果说分布式有啥负面效果,我觉得就是伴随分布而来的切换,虽然分布式有这个副本,那个副本,但是毕竟集中式下都是靠自动冗余,自动切换完成的,分布式下的很多切换都是跨设备,跨系统,跨机房,跨中心,中间的影响环节太多,可能产生以外的因素也很多,只能通过工具不断完善。

这里还有个决策问题,工具可不是简单的一键操作,而是带有自动决策的能力,在一个分布式环境下,如何作出准确的判断,如何确定正确的切换动作,不容易 .

领导领导领导

重要的事情说三遍,在互联网企业中,业务和 IT 是一个盈利共同体,很多情况下业务部门能够为了自身的盈利目标,对于技术有很强的包容性,因此分布式实现程度很高,但是在一些分工明确的企业中,业务的盈利部门, IT 是花钱部门,没人想对技术的缺陷负责,也没人能相对成本负责,业务说出了问题都是技术的错,反正我没错,技术说带病上岗出问题要有人担责,因此这时候就要求有强力的领导来决策。

当然,如果给领导成立一个具体的决策小组更合适,但是要能够同时管控业务和科技。

结束语

时间因素 , 很多方面没有展开来讲 , 其实分布式是个很有技术挑战的课题。

本文并不论证到底是分布式好还是集中式好,不能说每个人都骑自行车,方便又自由 , 所以火车又贵 , 又经常晚点,就不好,适合自己的才是最好的 ; 也不是说价格便宜就最好,在现实生活中,坐飞机是大家普遍的追求目标 , 自行车虽然便宜,但飞机的故障率却最低 , 至少比骑自行车低 . 分布式和集中式都要靠各自的生态才能存活,双向结合也可能是比较合理的选择。

从企业的角度,你是雇佣一个能做所有事情的高工资的强人,还是管理一堆有职责分工,工资低廉的平常人,从管理的简单性和自主可控性,可能得到不一样的结论,很多情况下是由于商业上的一些需要导致了技术的选择,如果能用三个臭皮匠自己组装出一个诸葛亮 , 无疑提升了自身的选择空间 . 但要看你自身是否是能管控住三个臭皮匠。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论1 条评论

ZhuJun2014ZhuJun2014存储工程师, IBM
2019-07-02 21:07
孔老师,没想到在这里又相会了。看完文章,学习到很多。我从自己熟悉的存储领域,讲讲对分布式在存储层的一点点理解。等我回头有空先。^_^

twt社区管理员@ZhuJun2014 期待朱老师的分享

2019-07-03 08:56
Ctrl+Enter 发表

本文隶属于专栏

趋势观点
本专栏的文章全部来自国内外行业或领域一线最强实践专家的深刻洞察,他们的分享如同为正在摸索前进的更多同行和企业带来一盏明灯。他们的观点也为企业迎接趋势挑战、克服各种困难提供了最好争议的标的。希望有更多一线最强实践专家加入趋势观点栏目,你们是推动中国企业IT应用最值得尊敬的人。

作者其他文章

相关文章

相关问题

相关资料

X社区推广