Ping++创业初期与CMDB架构演进.pdfVIP

：首席架构师

时间：

孙兵兵Ping++系统部

首先，非常高兴有这次机会来给大家，我们Ping++创业初期快速架构实现。为什么讲初期？

Ping++成立于2014年到现在有三年，发展到现在光Ping++运行服务有上百个。今天主要讲初

期，是Ping++创业头一两年时间里，这个架构是如何变迁。

今天讲的是两个部分，一个是API架构，另外一个是CMDB架构。

无论架构，所有的架构都要从业务谈起，Ping++是最初2014年开始做聚合支付，聚合

支付实际上是这样的一种架构是存在于各个支付，、、各个商户，小红书各种，包

括O2O这都是一种商户，我们是存在于这两端中间机构，所以聚合支付又称为第四方支付，我们主

要作用是帮助商户，我们的客户，将他们在、以及其他支付接口进行聚合，每一个

都有自己接口的，开发接入过程当中很，后期多个账目管理、支付管理是很

的事情，支付接口进行统一封装，所有经过我们这里就有统一，整个开发、运

维、运营就会变得非常简单。

随着业务发展，我们以接口管理为，拓展其他很多业务。比如数据分析、订单管理、、

差错管理，当然支付也会越来越多。无论如何发展，对Ping++来说，主要服务是以API形

势向外开放。所以第一讲API架构。接下来分三个阶段讲API架构。

第一阶段，称之为小而快简单架构。这个时期Ping++是以开发业务为主，怎么运维，怎么应付

大流量不是这期间主要讨论的问题。所以这期间我们的架构追求是小和快。

讲一下技术站，一开始使用世界上语言PHP，有了PHP很多人了解LNMP架构，这个架构是

非常流行的，可以简单看一下。这样一个非常简单的架构，这是API1.0架构，这个架构特点只需要关

心中间API服务层，一开始数据库都不关心，这些交给第云服务处理，从这些名字来看我们交

给阿里金融云处理，这个时间只需要关心API代码开发，只需要关心业务就可以了。这个时期其实

是伴随Ping++有一年时间，也就是Ping++整个开拓市场的时间。这个时期可以简单总结，一开始讲

到这个架构是小而快架构，主要体现一个方面，我们使用大量的成熟服务，负载均衡、数据库服务，

这个时候一个是部署简单，而且是非常灵活，可以对我们的业务模块进行横向扩展，这一段时间客户

进行了一个比较大的增长，也可以通过服务器这种水平扩容实现应对。这个时期很多人可以从刚才图

中看到，这个架构可以总结一下是瓶颈非常明显低级架构，只有三层，数据库是非常容易成为中

心。

刚才讲到可以无限扩展中间层，下面一层无法扩展，随着业务发展，数据库就会撑不住你的业

务。所以这一段时间进入2.0时期，整个2.0称之为轻而快的分层架构，这个时期架构并不是主动

过程，而是基于当时一个重构，很多在座大多数是工程师，对重构这个词不陌生。正常情况下在一个

服务开发过程当中，从第一模块到第二模块到越来越多服务。第一模块做规划，第二模块叠加也是非

常有序，到第三第四个随着开发人员增加，团队增大，业务快速发展，我们设计时间越来越少，我们

代码、模块、其他服务都会趋于无序状态，这是Ping++第一年过程当中经历的一个过程。这个阶段

以后，我们不可能让这个过程持续进行下去，所以我们希望在接下来一段时间内，包括我们新的服

务，包括已有服务，一方面希望新服务是独立有序的，对于已经有的，包括上面看到无序服务，开始

进行一个简单拆分，最终希望达到的效果，是通过逐渐迭代，将所有服务进行拆分，而达到一个便于

，而且是有序的目的。

这之前可以先回顾一下，我们第一阶段服务是等同的，是一个无限扩展，随着重构进行，所有

服务不是等同，每一个服务有自己的职责。结合1.0时期架构，面放一个负载均衡器，这样问题

就出来了，不同服务功能肯定是不一样，也就是接口肯定是有区别，光一个单纯负载均衡器已

经需求，流量进来到什么服务上，完全是无法控制的。所以这个时期我们希望引入一种新

架构，这个架构主要部分是在所有服务之前，我们部署API层次，这是我们自己开发的服

务，我们之所以引入这个，是出