1、一些数据
电商的业务复杂度，可以通过些数据来说明。单一个很明显的例子，2009年左有，当时商品详情系统的PV才1亿左有，到了2016年已经近50亿了，翻了50倍。而当时的系统架构和现在的架构完全不可同日而语。
2.系统规模的复杂度
一个复杂网站的系统架构一般会经历如下的演变过程。
(1)单系统。早期业务简单，定，每天晚上都需要把系统重新启动下。 单系统阶段也可分成两段:最早是花50 几台机器就支撑了一个业务系统。刚开始系统不稳万元买的一个PHP系统；随着业务的发展，系统逐步改造成了Java技术体系， 名字叫Denali。
(2)分布式业务系统。到了2007年，团队已经有了上千人，项目支撑面临巨大的挑战，系统架构必须升级进化。这就开启了第二个阶段:分布式业务系统阶段。我们开始做分布式战略，把原来的单系统拆分成多个高内聚、 低耦合的中心化系统。现在大家耳熟能详的用户中心、商品中心、交易中心、店铺中心都是这个阶段出现的。这同时也意味着把上千人的团队拆分成了业务相对比较集中的小团队。每个独立的系统可以独立设计、独立接需求、独立发布，整个研发效率和系统稳定性都上了一个台阶。
(3)业务平台。电商发展的速度实在太快了，到了2011年，随着各种B2C网站、各种导购网站的出现，可能会把一个大型网站从组织架构上拆成几个独立的事业部。多个独立事业部的业务决策链路更短、业务发展更快，技术人员也快速增长。事业部的定位不一样、业务发展方向不一样、业务的管控规则不一-样，甚至在一-些业务规则上 还可能相互冲突。
我们都知道，在做业务系统的时候，为了快速应对每天的业务需求变更，很多时候都是通过代码来写业务逻辑的，而在业务抽象建模，系统架构的开放性方面都很不成熟这会导致业务逻辑之间的耦合 和相互影响，大幅降低研发效率。系统架构必须升级，这就开启了第三个阶段:业务中心平台化阶段。什么是平台?就是要把基础能力和每个业务方的特性业务拆分，隔离业务和业务之间的逻辑。比如说两个相似的业务方业务有可能是冲突的，但他们需要在同一个平台上执行，这时我们必须把业务的逻辑分开。这个阶段开始升级会员平台、商品平台、交易平台等等。平台化最核心要点的是业务抽象建模和系统架构的开放性:业务抽象解决80%的共性问题，系统架构开放性解决20%的个性化问题。
(4)业务中台。随着生态的复杂度、业务的复杂度、系统复杂度的升级，又遇到了新的问题。领域的平台化虽然解决了领域内部的问题，但是每一个业务的执行都是跨领域的，涉及会员、商品、交易、营销、店铺、评价、支付、物流、售后等等.....一套业务逻辑横跨几十个系统。比如一件衣服的商 品发布规则、交易规则和营销规则均分散在不同的系统中，而且相互关联，时间一长就没有人能说清全局了。如果程序员通过翻查代码还原出所有的逻辑，代价极大。事态发展到后来，我们会发现评估需求的成本可能会大于实际开发的成本，而真正有效的工作占比很少，导致整个研发效率和业务响应速度都比较差。这已经不是单纯的技术问题了，而是复杂生态的协作问题。这时，我们开启了第四个阶段:业务中台化阶段。此阶段主要解决信息获取成本高、互联互通成本高、服务具有不确定性和低水平重复建设这四个问题。
那么，如何来解决这些问题呢，我们可以了解下传统的建 筑行业和互联网本身的基础设施建设，基本上都要靠三样东西来共同解决复杂生态的协作问题:
协议标准、运行机制。
满足标准的分布式执行单元。
中心化的控制单元。
比如移动互联网，我们现在之所以上网能用手机，它的根本是什么呢?网络的协议，也就是我们对网络的理解，它是基石。在这个前提下，我们的各种设备，不管是什么品牌的手机，只要满足3G协议、4G协议，就可以插卡上网。也就是这张SIM卡确定了我们的身份，从运营商控制网络上获取了控制信息，它知道我们是谁，能不能上网，网络速率等等信息。再回头来看我们的电商生态，就是要根据我们对商业的理解，把一些基础协议梳理出来。例如什么是业务?什么是业务身份?各个业务领域的边界是什么?每个领域提供的基础服务是什么?领域服务和领域服务之间的流程链接标准是什么?之后，再在这些思想的指导下建立业务平台化的实施标准和业务管控标准。因此，电商业务中台是一套由业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，能够给各业务方提供快速，低成本创新的能力。
(5)构建基础平台。从业务开发角度来看，中台主要是为了提升业务的开发效率，此处的开发效率主要是指个人协作的效率。如果换成从机器维护的角度来看分工协作，那么技术要解决的无非就是数据、算法和计算三方面的问题。
数据。哪些数据有效，哪些数据重复，数据该放在哪个数据中心；
计算资源如何利用。平时大部分机器的负载都比较低，如何有效利用这个计算资源，在高峰和低谷都能充分发挥它的作用；，计算和数限的协作。计算和数据是香放在一 起?如果不放在一起，迁移数据就要考虑带宽问题，会增加新的成本变量；，计算性价比的评估，依赖于算法。
数据、计算资源和好算法才能构建出优秀的基础设施，在此基础上才能给上层业务提供更好、更稳定的基础，所以搭建高效的基础平台是非常重要的。
3.组织管理的复杂度
其实复杂的问题都不是技术上的，往往是人和组织上的，所以如何提升人和组织的效能就比较关键了。
(1)呼唤全能工程师。在几十个人维护一个单系统的情况下，决定效率的就是这几十名工程师的技能水平，每个人的效率往往就决定了整体的效率。这种情况下Superman能发挥很大的作用。
(2)呼唤系统架构师。当一个团队达到上千人时，单系统肯定搞不定了，必须要构建分布式系统了，工程师必须要分工了。这个阶段最容易从业务开发团队中诞生中间件团队，他们专「]解决系统之间的连接问题。这个时期也会诞生一批能力比较强的系统架构师，他们决定系统该如何设计以保持高可用、高性能和高扩展性。从组织建设上，整个团队会按照技术分工的维度进行细化拆分，如:
产生架构团队即系统架构师，对整体的系统架构进行规划， 保障总体设计的高可用、高性能和高扩展性；
产生业务开发团队即业务开发工程师，专注实现业务逻辑的开发；
产生中间件团队，专注开发和维护系统中一些通用技术组件，为业务开发提供支持，提升开发效率；
产生UED团队，解决界面交互问题；。产生测试团队，保障开发的可用性问题。
(3)业务平台团队诞生。当团队达到几千人时，光靠技术角色分T已经无法解决问题时，就必须开始平台化建设，也就是业务架构师要发挥作用的时候了。公司的每个业务领域必须进行平台化建设，如电商业务中进行商品平台、交易平台、营销平台、会员平台的拆分。这些拆分后的平台再为上层业务提供基础的服务，便于上层业务进行更多元化的组合。在这个阶段组建业务平台团队是最合适不过的了，这样可以解决公共基础业务的集中管控问题，避免基础服务的重复和无序建设。
(4)业务中台组织诞生。当公司规模达到几万人时，一般公司都会采取多个垂直化事业部的组织形式，每个事业部-般都是全编制的技术团队，这其实也是重复造轮子最严重的时期。但是，一些基础的业务能基于业务平台中的service构建业务吗?其实也很难!因为人员一旦增多，再靠人与人之间的信息传递已经不可能有效运转了。例如你甚至很难知道公司当前到底提供哪些服务了，因为如果没有机制保障服务的注册和发现的话，它的获取成本会非常之高。此阶段影响效率的主要就是信息获取成本、互联互通成本和违约成本。
当公司达到上万人甚至几万人规模时，必然存在以下两种情况。后中管第一，没有一个平台型的业务部门，例如公共业务平台、中间件、基础技术平台。在这种情况下，各垂直业务部必然会建设各自的平台，产生大量重复建设，导致某些技术基础设施和业务基础服务不统一，甚至公司的技术栈都不一致，严重影响公司的效率和长远发展。
第二，有一个平台型的业务部门，但是也会出现各种问题。
不知道谁有什么样的服务能力、由谁提供支持、服务质量如何，团队信用度如何；
找到了有能力的团队，但BU目标不一致，不一定会获得支持；
沟通不畅、对同一个名称的理解各异(“多国语言”)，需要“翻译”；支持的质量与个体能力有差异，具有不确定性；
系统间协同难:同一个需求需要在多个系统中实现，相互连接需要定制，导致成本高；
后续支持不可控:开始支持，后续不支持了，没有显性违约成本；。支持方即便做得好也没有可度量的标准，缺乏长远的动力。
显然第种情况我们是不提倡的， 无法持续发展；但是第种情况也会存在各种问题，这些问题也正是构建深圳网站建设业务中台需要解决的问题。
本文地址：//www.xrqsnxx.com//article/4464.html
