艾锑无限讨论：企业核心系统架构选择分布式还是集中式

 抗击疫情的战“疫”已经打响了近一个月。目前来看，随着疫情的不断发展，现在可谓到了疫情防控最关键的一个时期，显然一个稳定运行的核心系统架构，能够更好地保障业务的稳定性和连续性，无疑对企业而言有着重要的价值和意义。从这个角度来说，重新审视核心系统架构转型到底是采用集中式架构还是分布式架构就变得至关重要。尽管这已经是一个讨论许久的话题，但此前业界经常用唯技术论的二元对立的观点，往往脱离了用户的具体需求和能力的讨论，总是不能得出一个令人满意的结论。因此，笔者认为，一种结合实际场景的“稳”“敏”兼备的、平衡的系统架构，才是既能满足业务需求，即时产生业务价值，又能有效支撑企业架构转型的稳妥之路。

此前，分布式架构“阵营”认为，随着互联网和云计算的兴起，集中式架构已无法轻松应对海量用户、以及高并发的应用场景，同时其系统升级迭代复杂，难以满足新环境下快速创新的需求，走向分布式已是大势所趋。

而集中式“拥趸”们则认为，集中式架构在企业的核心业务中具有“不可替代”的地位，因为它以成熟、领先的贯穿全堆栈的系统优势，为用户带来在开发交付和运行维护上更大的专注性和稳定性。

事实上，这种“二选一”的评判标准已经过时了，今天绝大多数企业的架构早已不是单纯的集中式或者分布式，而往往是“二者兼顾”。更重要的是，无论是集中式架构还是分布式架构，都是开放式的技术堆栈，其技术特点也“各有千秋”，都在企业核心系统中扮演着不可替代的角色。

其实，如果我们回顾计算模式的发展历史，就会发现一个简单的规律：那就是计算架构往往在集中式和分布式之间不断演进，往复式发展前进的。从这个角度来看，企业未来架构的转型关键，就在于要秉承一种开放心态，根据自身不同的业务需求，把新兴的和经典的技术与架构做到“为我所用”，并在分与合之间把握好平衡之道。

分布式架构的流行与挑战

众所周知，分布式架构是一个硬件或软件组件分布在不同的通过网络连接的服务器中，彼此之间通过消息传递进行通信和协调的架构。在网络连接允许的情况下，分布式架构中的服务器的拓扑部署相对灵活。

今天，分布式架构正被Google、Amazon、Facebook、阿里巴巴、腾讯等互联网公司所推崇。一方面，由于流行的分布式架构多采用开源软件和消费级的硬件，因此在价格成本、自主研发、灵活兼容、伸缩扩展方面有比较显著的优势；另一方面，由于互联网行业具有请求量大、数据量大的特点，业务上又可能在集中的时间段出现高于日常流量数倍的业务高峰，超强的弹性伸缩能力可以最大程度的支持海量用户以及大规模并发的业务场景。当然，在这些全球互联网巨头具体的实践中，其分布式架构的运用也都是在充足的财力和人力条件下保证的，可是对大部分企业而言，如果将之作为一个重要的参照，或者赋予分布式架构极高的期望，而不了解背后的成因，其实也会带来很多“负面”而深远的影响。实际上，分布式架构从理论模型上说，就不是一个很完美的模型，尽管它把各种各样的硬件平台，各种各样的框架，以及各种开源软件“整合”在了一起，看起来很完美，但由于分布式架构始终存在硬件、网络的隔离，对于一些事务操作不像集中式环境下那样简单。CAP理论就从理论上证明了分布式架构的不完美性，同时也告诉架构师们不要浪费时间和精力在分布式系统中追求完美。所谓“CAP”，是指Consistency（一致性），由于分布式环境存在多个节点，这些节点上的数据在同一时间所存储的数据必须是一致的，这就是一致性协议；Availability（可用性），即任何时刻需要保证服务的可用和稳定；Partition Tolerance（分区容错），即某个时刻出现网络或者硬件不可用，甚至宕机，其它的机器也要能保证正常可用。在分布式系统架构下，CAP三件事不能同时兼得。从实践上来看，只能通过妥协的方式达到一定程度的兼顾。与此同时，分布式架构或系统严重依赖网络的服务水平。采用廉价的、不可靠的硬件的分布式架构，希望通过冗余的方式达到可用性指标，这里面的沟通和协调工作很繁重。网络的质量和性能成了分布式系统的生命线。然而，网络本身也是一种有限资源。例如，带宽是有限的；速率是受限的；延迟是不可避免的……。再如，分布式是一个很庞杂的系统，包括服务器、支撑软件、应用软件、路由器、交换机、网络带宽、信息安全等等都需要人员维护，特别是在当前疫情肆虐的当下，最大限度的减少运维人员暴露在现场，降低感染几率也十分关键，而这也给分布式架构的运维管理工作带来了更大的挑战和压力；此外，迁移成本方面，目前主流数据库仍是集中式数据库，同种类型迁移简单，如果替换为分布式数据库，应用系统几乎要推倒重来, 迁移成本和风险也巨大。

不难看出，分布式系统看起来很完美，但实际上出现问题的几率也同步增加，因此尽管目前分布式架构“大行其道”，也要理性看待其面临的潜在风险与挑战。

集中式架构的开放与创新

回头再来看集中式架构，它是以大型主机的技术堆栈为依托，并在半个世纪前开启了以服务器处理为核心的计算时代，同时伴随业务、数据的大集中处理发展成熟，在这个过程中始终立足于关键事务处理的企业计算，由此也催生出了“经久不衰”的集中式架构。在集中式架构系统中，我们能够看到一些典型的特征，如精简的系统部署、充裕的横向和纵向扩展能力、连续的业务可用、集约的运维规模，专注于业务的开发模式，以及更好的架构包容性等等。从这个角度来看，特别是在非常时期，集中式架构显然能够更好的发挥关键作用，可以让企业集中人力、物力做好核心业务系统的运营和维护的工作。如果追根溯源，集中式架构之所以能够“历久弥新”，关键是其以Sysplex 这样一个最优秀的经典技术堆栈集群来实现核心业务处理的，本质上它也是一个“分布式系统”，但它的优势在于：通过共享内存(CF)，实现了并行计算；通过CFLINK这样高速可靠的连接实现通讯，由此保证了同步模式的集群实现；此外，提供ETR(STP)，Sysplex更实现了集群统一的纳秒级高精度时钟服务。可以看到，集中式架构通过Sysplex这样的一种与众不同的计算模式，由此为用户提供资源共享和数据共享；精简的系统部署；充裕的线性扩展能力；平衡的水平/垂直扩展能力；灵活的OnDemand容量扩缩；连续的业务可用性；集约的运维模式等等。更为重要的是，Sysplex同样保持了与时俱进的能力，是一个能够着眼于支撑不断演进的新技术与架构，特别是在如今的混合多云环境下，它还提供了两个最为重要的能力：一是专注于业务的开发，它始终将成熟、领先且贯穿全堆栈的系统优势，换取用户在开发交付和运行维护上更大的专注性；二是更好的架构包容性，即使通过集中式这样的经典架构，在今天用户也能借助这个架构开发很多的新应用，如微服务、云原生等等，都可以利用主机构建的集群架构来实现开发与部署。

也正是因为如此，今天集中式架构在企业的核心业务中具有不可替代的地位，同时这也是全球绝大多数大型商业企业选择集中式架构处理企业核心业务的重要原因。

集中式与分布式正在融合

当然，在经过多年的发展之后，集中式和分布式也正从过去的“二元对立”，逐渐走到了“相互融合”的新阶段，无论什么样的架构方式，都是为了解决企业核心系统面临的新挑战，其价值可谓“殊途同归”。背后的原因是，不管是集中式还是分布式，从技术层面都要解决四个问题，即高可用、扩展性、负载均衡性以及性能；而从用户层面看，则是解决安全和稳定的问题。所以，针对这些诉求，集中式和分布式只是在技术手段上表现出不同的实现方式而已。

以高可用为例，集中式架构通常会采用集群部署、主备复制和主备切换的方式来实现。同时，集中式的容灾方案比较成熟，沉淀了数据复制、镜像快照、一体化迁移等一系列容灾相关的技术，几种典型方案包括一主多备、同城双活、两地三中心等，都可以从容应对各种场景。历经半个世纪的磨练，集中式架构在运维管理，自动化操作等方面也自成体系。而分布式架构则会通过多节点、多机房等技术手段，这同样也保障了系统的整体可用性。此外，分布式架构由于采用自动化的运维和监控以及故障处理体系，如集群的自动初始化，生产过程中的随着业务流量进行自动扩容与缩容，以及出现了故障以后服务的自动降级、熔断等等，同样也在一定程度上实现了系统的可用性。再以数据库为例，通常业内的看法认为，集中式数据库在事务强一致性、稳定性、迁移成本和运维管理方面相比分布式数据库有着天然的优势，特别是从安装部署到应用开发，从运维监控到数据灾备，既适合大数据量业务应用场景，也适配企业内部IT运营环境。此外，随着私有云的发展和容器化技术的普及，集中式数据库资源可以通过池化部署快速供给，而且各资源独立，应用隔离性好，数据安全性高。但基于分布式的数据库就“难堪大用”了吗？其实这个结论也并不正确，而是它以最终一致性替代强一致性，以基本可用性和最终一致性作为目标，保证了互联网web系统的高可用和业务连续性。而在创新型应用的支持力度上，分布式数据库同样也有很多“契合点”，保持支持海量数据、复杂数据类型、高可用、人工智能、弹性伸缩、业务灵活调整和成本。

由此可见，企业业务的多样性决定了两者并不是“互斥”关系，更多应是“互补”关系。正因为如此，越来越多的客户今天正在采用集中式与分布式相融合的架构体系，通过集中式架构保证核心业务平稳运行的前提下，分布式架构则可以更好的满足互联网等新的应用场景，由此实现快速的创新。

走向稳敏兼备的未来架构

在此背景下，当企业核心系统出现集中式与分布式相互并存，或者相互融合的情况下，显然对企业整体的管理和运维难度又提出了新的挑战，在这样多形态并存，或者说混合架构所构成的环境下，如何实现向混合云乃至云原生的演进，无疑也是业内关注的核心话题之一。具体而言，面对复杂的混合架构，企业势必需要一个更加统一的管理平台，能够对集中式和分布式的架构进行高效的管理，同时能兼顾发布、部署效率和稳定性，此外在运维管理上，也要能够实现整体性、一致性的管理。从这个角度看，企业未来架构要解决的核心问题，就是要实现真正的混“合”，做到核心系统架构管理和运维的“有机统一”，而不是混“杂”，即尽管貌似相互融合到了一起，但依然还是出现“你还是你，我还是我”的困局，那样不但解决不了用户面临的架构痛点，反而还增加了更多的运维管理难题。同样，未来架构的选择上，也应该本着一切从业务需求出发，从客户体验出发的原则，不能为了追赶技术潮流而追赶技术潮流。