从能力开放平台到能力中台构建思考

　　今天谈下能力开放平台和能力中台方面的话题。首先我们还是先解释下对于能力开放平台和ESB总线引擎，API网关等的一个关系。
　　即能力开放平台一般包括两个方面的内容，一个是能力的形成，一个是能力开放和运营。
　　对于能力的形成来说，有可能是能力本身就是自己产生和自建能力，也可能是聚合的第三业务系统或合作伙伴的能力。不论是哪种情况我们都需要考虑这些能力接口的统一注册接入和管理，而这部分即是通过ESB总线或API网关来完成。
　　其次就是能力开放和运营，即我们需要形成能力的接入，能力的消费，能力像商品订单一样的订购，计费等业务管理，包括后续的能力运维服务。而这些一般来说标准的ESB引擎并不具备，而是体现在能力开放平台里面。能力开放平台的整体架构
　　对于能力开放平台架构可以参考上图，具体分解为如下平台和子系统。
　　开发接入平台
　　能力开放平台是构建一个大生态体系，那么对于API接口服务能力的提供不仅仅需要依靠自有能力，更加重要的就是要依赖于开发商和合作伙伴的可共享能力接入。那么就必须为开发商提供一整套方便他们进行API快速开发，快速接入的平台，工具，标准规范流程，以方便他们进行API接入，同时尽量实现API接口服务接入中的自服务过程。
　　具体来说开发接入平台可以提供API的快速开发工具或开发环境，API开发框架，API开发指南和示例参考，API开发流程，API开发规范，API接口测试方法，API接口服务开发接入流程指南等。所有这些目的就是要让接入的API遵循一套标准的方法和流程，同时让开发商能够快速理解和学习掌握，方便API快速接入。
　　能力平台（能力库+服务目录）
　　这里的能力平台更多是能力引擎平台，实际上就是应该是ESB总线引擎，API网关或其他API接口服务集成平台。该引擎重点就是实现API接口的注册接入，API的服务代理和统一服务目录提供，API的安全，日志，流控，监控等各种拦截能力。能力平台简单来说就是要形成标准的API接口服务能力目录并向上提供。
　　在原来我们谈能力平台的时候往往会将能力引擎和上层的能力运营平台进行整合，形成一个完整的大平台系统，而这次在思考的时候进行拆分，拆分的目的就是实现底层引擎和上层能力运营平台的解耦。即上层的能力运营平台实际上可以兼容和适配底层多种能力引擎，这样更加方便进行组合。
　　运行监控平台(对API接口服务的运行监控）
　　运行监控平台即要实现对API接口服务的运行监控，性能分析，异常问题的实时告警和预警，接口服务运行的统计分析等。同时对于运行监控平台还需要基于最基本的原子服务监控层面进行延展，即向下还涉及到具体的中间件，数据库的资源监控，向上还涉及到服务链，端到端业务流程的监控。即：资源监控：服务器层面，中间件层面（包括数据库，应用服务器中间件），JVM监控服务监控：最基本的原子服务监控能力，服务运行监控，也包括服务链监控能力，APM监控流程监控：实现端到端业务流程的监控，而最终的流程监控可以通过服务链监控进行串联
　　运营管理平台
　　运营管理平台是整个能力开放平台中关键的生态应用，即我们涉及到的平台提供商，运营商，开发商，服务和内容提供商等最终都会使用运营管理平台，通过运营管理平台实现最终服务的整合。
　　运营管理平台在前面自己已经谈过多次，实际上底层可以参考电商平台的原型，而里面最重要的就是服务受理和订购中心，产品或服务配置中心，服务开通，服务计量和计费中心，客户中心几个关键模块。最终解决的问题就是让我们开放和接入的API服务接口能够最终配置为可以销售和运营的产品，并进行计费。
　　营销平台
　　大部分在构建能力开放平台的时候往往不会涉及到营销平台，但是类似典型运营商的BSS域就一定会有营销中心和本地化的服务网厅，而这些网厅的服务人员就需要一个营销平台为用户提供各种服务能力。在我们谈物联网云平台的时候也谈到过，在构建智慧家庭的完整生态平台的时候，往往还涉及到我们的产品服务地推，这些也涉及到需要有相应的平台和应用进行支撑。
　　运维平台
　　运维平台属于后生命周期，即在产品服务订购后，需要对服务消费中的问题进行处理和解决，并提供相应的售后服务能力，因此这块实际上需要有一个面向最终客户的运维管理平台和运费服务平台来进行支撑。
　　自服务平台(开发商门户，合作伙伴门户等）
　　自服务平台面向最终提供给用户的功能聚合，并实现客户的自服务能力。因此自服务平台本身又是一个面向用户角色的功能聚合平台。可以看到对于前面谈到的服务接入，能力共享运营，运维服务，服务运行监控等各个子平台都需要向最终的用户提供功能服务，而自服务平台则是这些功能服务能力面向用户的聚合，而不是全新构建的新功能。从能力开放平台到能力中台
　　在前面给出了完整的能力开放平台的功能架构，但是注意这是一个完整的技术平台功能架构，除了底层的API网关能力引擎外，包括了开发接入中心，运营中心，运维中心，组成一个完整的能力开放平台架构，但是这个是单纯的一个技术平台。
　　而今天要谈的能力中台则是一个基于上面的技术平台提供一个对当前有价值的业务能力进行聚合的业务平台，即我们说的业务中台+能力开放，因此我在这里将其简称为我们的能力中台。
　　简单来说，我们要构建的能力中台，就是对当前公有云各种有价值的业务API接口能力进行聚合，并重新进行梳理后给出一套面向企业，外围应用开发商的业务能力API接口服务目录，方便外围场景开发自己的定制化APP应用，同时也提供一整套的能力API开发接入，运维，运营管理后台能力。
　　任何一个完整的原子业务能力，往往在后端会有多个服务提供商能够提供这个接口，举例来说类似打车，充话费，支付，快递，订机票酒店，购物等等。而我们要做的就是分析这些开放的API接口服务，并对同类接口能力进行归并和聚合，然后面向开发伙伴提供单一聚合后的接口服务能力。
　　而这种能力聚合平台，实际价值究竟在哪里？
　　外围应用开发商不需要再去找一个个独立原子服务提供商单独去对接各个接口，而是直接通过能力中台完成一次性对接，同时完全采用一套标准的对接方法，接入和消费流程，接口运维管控标准。这将极大的方便开发商快速的定制开发属于自己的APP应用并快速上线相关应用。
　　我们可以想一个最简单的例子，比如我要在小区门口开一家士多店，一种方式就是我要联系米面粮油，烟酒，坚果零食的各个厂家，并且自己去购买相关商品才能够真正开张。而另外一种方式就是有一个中间商能够一站式的帮我配送所有我们需要的商品，我一个电话就搞定。而能力中台就是这个中间商，这个中间商为了提供最方便快捷，价格最优的聚合选择，但是他们不管开店，也不面对最终的消费者顾问。
　　其次，对于外围开发商来说，使用的是标准聚合后的可复用能力接口，而这个接口底层本身可以适配多个原始的原子服务能力提供商。客户也完全可以根据自己的需求来选择最终的提供商清单。这种方式下客户不会被一家服务提供商绑定，也更加方便客户灵活选择，避免独家。
　　简单来说，你使用了一个文件存储服务能力，原来可能用的是阿里云的接口服务，但是阿里云后续不提供该能力了，你在消费接口代码完全不用变动的情况下，就可以快速的适配到消费华为云的接口服务能力，这种适配是由能力中台完成的。也就是我们在谈SOA核心特点的时候说到的位置透明能力。
　　再次，能力中台提供附加的各种管控治理，运维监控，运营能力。其中包括了统一的服务订购，服务运行计费结算，也包括了后续的服务运行监控，服务运维和问题排查，服务日志审计。外围合作伙伴可以在能力中台一个平台上实现对所有消费接口服务的统一管理和运维监控，这不仅仅是方便了前期的服务消费和订购，同时也方便了后期的运维和管控治理。能力中台潜在场景
　　在前面我已经谈到能力中台可以理解为业务中台 能力开放平台的一个结合，即先有业务中台，然后将关键的业务能力以API接口服务方式注册和接入到能力开放平台对外开放，在开放的时候具备持续运营和管理的能力。
　　我们来看下当前可能存在哪些能力中台
　　电商能力中台
　　聚合各类电商平台的能力，可以理解为电商能力聚合平台，将类似京东，天猫，苏宁各大电商平台的商品服务能力聚合，同时提供最有价值和竞争力的产品和服务。这个聚合包括了订单，商品，物流，支付等各种能力的聚合。
　　这种能力中台一方面是给最终的电商运营服务商使用，一方面还可以给大型供应商提供服务，举个简单例子，你是一个大型的家电制造商，需要和各个大的电商平台对接，原来可能需要对接很多次各大电商平台，而有了能力中台后你只需要和能力中台对接一次即可，所有信息全部会自动发布到各大电商平台，同时相关的物流，配速信息也可以做进一步的整合提供。
　　商旅能力中台
　　对于商旅服务来说，构建能力中台也是一个大的方向和趋势，我们可以看到对于酒店，机票火车票，专车出租，旅游服务等服务商很多，如果一个APP应用要去对接这么多的原子服务商本身也是相当耗时耗力的事情，那么能力中台完全可以实现对这些能力进行聚合然后统一提供对外能力开放。如果你要做一个商旅APP应用，那么就相当简单，只需要和商旅能力中台进行对接就可以了。
　　服务类能力中台
　　即我们常说的各种服务类能力聚合，类似的常见有福利服务，社区类民生服务等。也就是我们常说的衣食住行，吃喝玩乐，教育健康等实现一个顾客需求的常规服务能力的大聚合。这种聚合比较常见的例子我们可以看到类似现在的58同城就是一个对常用家庭服务的能力聚合平台，你家庭需要的保姆，电器维修，二手物品处理，洗衣等各类服务能力都进行聚合。你基于这个聚合能力，可以快速的开发类似智慧小区或社区的服务平台。
　　服务类能力中台可以方便运营商快速的开发各类服务类APP应用并快速的开始运营和服务，而对于能力底层究竟是哪个原子服务商并不需要太关心，这本身也是快速的推出应用的一种最佳方式。
　　在我博客前面讲过ServerLess架构和服务，实际上可以看到以后应用的开发很可能就变化为这种模式，即更多的是各种中台服务能力的聚合，重新组合和编排就快速的形成应用。从能力中台到生态构建
　　生态这个词是我们用的相当多的一个词，比如经常谈到的互联网+行业生态体系，谈到的智慧城市生态体系。那么生态的本质究竟是什么？如果再简单的来给生态一个定义，即：
　　生态是通过对整个产业链上下游，外围辅助服务提供商的链接而形成的一种相互依存并共同获利的体系。个体不能单独存在，而必须围绕整个生态获利，同时只有完整生态才能够为用户提供最大价值交付。
　　这些链接可以是资源，也可以是服务，也可以是资源+服务的整合，但是最终都必须通过信息流实现贯穿。信息的贯穿和整合往往提升了整个生态体系价值和可达性。
　　一个好的生态体系一定不是静态的，而是动态的可自我调整的，这个生态体系可以通过外在需求的变化及时进行内部链接和信息重构。
　　连接是构建生态的第一步
　　当我们构建一个大的生态体系的时候，连接往往是第一步，即我们首先要梳理清楚这个生态体系是如何运转的？究竟涉及到哪些上下游，涉及到哪些参与方，各方在整个生态体系里面究竟起什么作用？提供什么能力？把这些都梳理清楚后，我们才能够开始将各方面接入到我们整个生态体系里面。
　　注意在我们构建一个生态体系的时候，生态里面各方的连接一定不再是传统的点对点连接方式，而是变成了一种类似总线式的连接方式，各方都只和生态系统对接，相互之间不直接发生关系。这个和我们前面谈到通过能力中台进行能力聚合类似。
　　一个生态体系要是开放的而不是封闭的，因此需要具备完全开放的能力接口给外部，方便外面各个参与方快速的并自服务的接入到整个生态体系里面来。
　　对于生态的各个参与方来说是连接和接入能力，但是对于整个生态体系的建设和运营方来说，则是外部资源和服务的聚合能力，这和我们经常谈的服务能力中台和能力聚合平台往往是一个思路。运营方并不是自己去单独建设各个能力，而是充分去聚合外部垂直化已有的专业能力，通过聚合形成资源和服务能力的连接，通过连接后进一步来提升对外服务的价值。
　　那么由谁来构建和运营整体生态体系？为何能够完成整个聚合过程？其核心在于：运营方本身就具备了核心资源，类似于各种数据资源，资源本身即价值。运营方本身对某一个垂直领域有深入的业务经验积累，即清楚如何聚合资源并创造价值。
　　协同是产生价值的关键
　　要知道在构建生态体系过程中，连接往往本身并不产生价值，而协同才是产生价值的关键。即基于客户需求，基于业务场景，我们连接和聚合有的这些资源或能力，这些参与方如何来高效的协同完成最终的客户需求和业务场景，这个才是产生价值的关键。
　　如果我们是生态体系的运营方，那么我们要思考的就是对于聚合后的各个参与方，各个资源服务，如何基于业务场景去实现高效的协同，去组合和编排这些资源来满足业务场景的需要。你对业务场景的理解越透彻，你就越清楚应该接入哪些资源，也越清楚这些资源究竟应该如何协同和联动。
　　谈到这里我们看到和我们经常谈的SOA思想的两个关键点很类似，即第一是接入可以复用的接口服务，第二是基于业务流程去组合和编排这些服务能力。
　　对于单个资源，单个参与方你能够提供的都是单点价值，但是对于整个完整生态来说，就可以提供整合后的组合价值，这种组合价值往往更加具备竞争优势，也更是客户所需要的。这个有点类似我们项目实施里面谈到的交钥匙项目一个道理，客户需要的就是一个交钥匙工程，各个参与方如何去协同和组合，完成高效运作是生态体系内部的事情客户并不需要关心。
　　生态的终极目标应该是高度自治和自我持续优化的
　　一个完整的生态来说，对外是足够的开放，对内又是高度协同自治的。而生态发展的终极目标就是生态体系本身就是一个完整的高度自治，能够自我优化，自我修复，自我进化的体系架构，在这个过程中并需要太多的人工干预，这才是一个最佳生态。
　　生态的运营方一开始由于是清楚业务场景，往往参与生态体系的构建，也参与协同能力的制定，即运营方可能既是游戏规则的制定者，也是参与者之一；而到了后期，运营方应该仅仅应该是游戏规则的制定者，而不再参与具体的游戏，而游戏究竟如何演进是整个生态体系自己去进化的。一个好的规则只需要确保生态体系能够按照健康，可持续的方向去持续进化和改进发展即可。
　　生态体系要考虑的就是制定好各个参与方的接入规则，生态暴露能力的消费规则，生态接入的各个参与方既可能是消费者，也可能是生产者，同时还可能同时兼顾了消费者和生产者两种角色。这些生产者和消费者之间应该如何去协同在后续应该只自我去进化的，生态运营方反而不需要去强制制定各种协同流程。