互联网花了10多年的时间，已经培养出了用户在线购物的习惯，如今稍作点击，在京东11点之前下单，当天就能拿到我们中意的商品。
与大用户量，高并发量匹配的
电商技术体系，相对比较成熟
：高可用，可扩展，水平切分，服务治理，微服务架构已经完全能够满足2C电商业务的需求。
与2C类个人电商相比，面向企业级采购的2B类电商依旧十分之痛，特别是流程和效率一直是一对难以调和的矛盾：
在这样的背景下，京东瞄准了其中的机会，提出“企业智慧采购”概念，以“企业采购解决方案提供商”的身份，全新推出
TESB（京东笛卡尔平台）
，以化解采购流程中“合规”与“效率”之间的矛盾，京东试图变革采购模式，让整个过程变得阳光、高效、透明、简单。
2C类电商技术架构相对成熟，
TESB（京东笛卡尔平台）
这类企业采购平台又会面临哪些技术上的挑战呢？
首先是消息转化上的进化。
成熟的ESB产品，一般会采用开放性的传输协议和消息格式。例如使用HTTP传输协议携带查询请求、采用EDI报文来进行企业ERP对接、采用MQTT消息描述物联网设备采集内容等，但在实际的企业对接过程中，企业的信息化水平参差不齐，尤其是一些中小型企业很难按照这些标准完成对接工作，因此
TESB（京东笛卡尔平台）
需要去适应这种需求，就要求其在消息转换上具备灵活性，既要支持标准的开放性的传输协议和消息格式，也要支持企业定制化的传输协议和消息格式，同时实现标准到非标从协议到数据层面的互通。
如上述架构图所示，所有的业务系统都需要和平台进行交互，系统设计时需要预留一层adapter层，adapter与平台的接口是固定的，由adapter与业务层进行直接交互，对业务层屏蔽平台的复杂性。
当需要有新的业务侧接入平台时：
通过这种方法，保证系统的扩展性。
其次是流程编排上的进化。
在企业对接的过程中，
TESB（京东笛卡尔平台）
在面向数据转换过程的同时，需要面向业务服务。而采购场景是复杂的交易场景，传统的ESB根本无法满足业务需要。
在很多采购交易场景中，需要定时定点的进行服务交互、需要fork和join支持，这里不仅仅单单指的是数据的合并，也牵扯到服务的合并，同时对服务的路由规则也提出了挑战，需要应对不同交易规则下的路由策略，而
TESB（京东笛卡尔平台）
基于BPM2.0标准，打造了自己的流程编排引擎，同时引入了推理引擎，建立了推责机制，来承担复杂采购场景下的服务集成工作。
流程编排对架构设计的挑战，是规则引擎与状态机的设计：
-
需要抽象出不同的业务状态，状态与状态之间保持相对独立；
-
设计规则引擎，针对不同的业务，只是在不同状态之间跳转，就如工作流一般；
-
增加业务流程时，如果所有流程状态都能复用，则只需要简单配置规则引擎就能实现扩展；
-
如果新业务流出现了新的业务状态，状态机需要增加一个节点，但对历史业务状态是透明的，不需要任何改动，做到了最大程度的状态解耦。
最后是系统工程架构上的进化。
京东作为国内首屈一指的电商平台，在系统工程架构上积累了丰富的经验，这些经验是传统ESB平台所不具备的。版本控制，服务隔离，健康检查，高可用可扩展，服务治理，微服务架构等一系列技术，均能够复用和传承到2B的企业采购电商平台上来。同时，cloud云计算，AI人工智能，IOT物联网，BI大数据，BlockChain区块链等新兴互联网技术，也应用到了智能化采购过程中涉及商品、展示、贸易、履约、财务、售后等7大核心流程中来。
工程技术能力是京东的优势能力：
-
版本控制
能够保证系统快速迭代与回滚；
-
服务隔离
能够保证通用服务的隔离性与扩展性；
-
健康检查
