企业信息化中台建设分析.docx
《企业信息化中台建设分析.docx》由会员分享，可在线阅读，更多相关《企业信息化中台建设分析.docx（21页珍藏版）》请在冰豆网上搜索。
企业信息化中台建设分析
企业信息化中台建设分析
2019年2月
随着只能化、数字化和互联网时代的来临，云计算、大数据、智能化、微服务、物联网、移动互联等各种新兴技术为信息（IT）产业带来无限机遇的同时，也为企业各类业务不断发展带来支撑，伴随着企业规模不断扩大、业务相关多元化、无关多元化、创新化的发展，“大中台、小前台”的技术架构模式出现，由于公司的发展要求，笔者经常接触大中台这一理念，结合SOA集成平台、IT治理、数据治理等产品和方案。
一、定义阐述
中台概念出现之前，在信息化模式上，前端为支撑业务的应用端，后端为各个应用系统，为前端用户，如：
客户、供应商、伙伴、社会提供服务，但随着市场、用户需求、业务的多变性，底层僵硬的应用无法及时提供支撑。
企业需要一个强大的中间层为高频多变的业务提供支撑，为不同的受众用户提供多端访问渠道，基于此类需求“中台”概念出现，不过凑巧是阿里提出，接着开始对企业客户、中间件厂商、数据平台厂商、甚至传统应用软件厂商都有较大的概念冲击。
恰逢此时，微服务技术和架构、容器化的生态、Devops概念和工具处于大发展的阶段，然后基于“大中台、小前台”的信息化建设模式开始流行。
1. 概念产生
对于大中台来讲，现在并没有十分严格的定义，每个企业对其的理解都是不同的，有的在技术上使用大中台模式，有的在业务上使用大中台模式，有的将两者相结合。
“大中台，小前台”的机制最初阿里提出的时候，主要应用于O2O线上线下协同、电商等场景，对于电商来说，市场环境是瞬息万变的，而前台是主要的一线业务，这时就需要一个强大的技术中台提供快速设计方法和系统性后端服务，去应对市场变化，灵活快速的做出应对策略。
然而随着时间的推移，技术在不断发展，电商行业在巨变，企业随着国家的政策支持，企业信息化建设也在发生着变化，也在积极探索如何搭上互联网的快车，实现企业的互联网转型，实现“人财物、产供销”互联网化。
这就促使企业的传统信息化通过异构集成、架构治理、业务碎片化、信息技术重构等使企业能够快速适应互联网时代的市场变革。
企业的信息部门需要在新技术和老的软件系统并存的条件下进行实践和与探索。
在整个微服务架构，平台应用的构建模式下，对于中台如何构建始终都是企业信息部门的一个重要的关注点。
中台本身就体现了SOA和业务的思想，体现了大架构规划设计中的微服务模块划分和服务识别。
对于中台，可以看到谈的最多的仍然是在互联网电商类应用中，电商上层的业务应用类型太多，变化也快，需要有一个稳定，可共享，可复用的能力中心来提供中台能力。
而对于各类运营商和服务商，类似电信运营商，中台的构建更多体现在BSS域，即面向C端客户或政、企B端客户的时候，渠道，网厅客服和业务办理，电商，自服务APP等，也都需要一个完整稳定，可共享能力的中台。
也就是说前台响应业务变化的需求也迫切，对敏捷的要求越高，越是需要有强大的中台能力支撑。
共性的东西，基础可复用的东西我都不需要考虑，只需要考虑如何去应用能力和组装能力。
①.大中台首先是一个由业务变更催生的业务概念
当我们一谈到中台的时候，很容易想到我们整体IT分层架构中中台层的构建，但是大中台首先是一个业务概念，要在业务上理解大中台产生的背景，导致的业务和组织架构变革，才能够更好的理解后续大中台如何构建。
要明白，技术一定都是为业务和流程服务的，业务和流程首先要变更，技术只是如何更敏捷的支撑而已。
阿里巴巴“大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。
就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
前台和中台本质上是工作分工的问题。
比如，某部门要开发一款App，是部门内部（大前台）自己组织一套技术、产品、设计、运营的团队，还是集团为其提供资源（大中台），由专门的技术团队来帮助其开发、设计产品等等。
所以说，“小前台大中台”的运营模式，就是美军的“特种部队（小前台）航母舰群（大中台）”的组织结构方式，以促进管理更加扁平化。
十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。
而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦查火力后勤支援。
所以如果中台没有办法承接前线的需求，前线就会不认可它服务的价值。
当我们开展具体的业务时，每个团队都需要有技术、产品、市场等方面的基础支持，传统互联网公司的每个业务部门都会有自己专属的业务、市场、产品等人员。
随着公司的发展壮大，许多业务部门内提供基础支持的工作可能会有很大程度上的重复（例：
两个相互独立的业务部门同时开发APP，两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码），信息不能共享，导致许多资源被浪费。
并且，每个业务团队的水平参差不齐，怎样使每个团队都能够在既保证质量、又保证效率的前提下完成任务。
为此，我们急需一个有效的机制来将公司内部的技术、数据、产品等资源进行整合，统一为业务线提供支持和帮助。
同时，各事业部就像一个个子公司，都是实行独立核算，导致各事业部往往从自身利益出发，影响事业部之间的协作，难以形成企业合力。
阿里巴巴近年来迅速扩张、员工众多，所以可能会存在管理不善、效率低下、各事业部各自为政等问题。
为了解决以上问题，阿里提出了“大中台，小前台”机制。
“小前台大中台”的运营模式促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活：
其“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。
前台要做什么业务，需要什么资源可以直接同公共服务部要。
搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷，让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难。
②.从业务到技术，技术要和业务匹配
前面在将大中台的时候，从业务概念和业务变革上面可以看到，业务的目标很简单，就是要资源整合共享，要敏捷灵活和快速响应，要扁平化和管理高效。
而这些最终在通过IT架构和应用系统落地的时候，这些刚好也是IT建设的关键目标。
如果业务上谈大中台小前台，那么在IT应用架构里面可以谈厚平台轻应用。
其中大中台为企业内部大的业务职能中心，对于到厚平台层能力中心提供；而对于小前台为前端的各类创新业务，对应到IT应用架构中的轻应用。
在平台应用的构建模式中，有一个关键点就是高效和敏捷，可以看到类似前面经常谈到的DevOps实现开发运维过程一体化和自动化，提升高效敏捷；而对于微服务架构，中台和前台分层，组件化和模块化，则更多的是能够更好的通过组装来响应前端业务。
中台和前台分层，中台的核心是提供各种共享能力，而前台的核心则是快速的组装和组合这些能力。
这也正是SOA架构的核心思想。
可以再看下原来我们对SOA架构核心的理解，强调最多的就是业务能力组件化和组件能力的服务化，而对于SOA定义里面的两个关键点，一个是找到服务，一个是组装服务。
找到服务：
中台的各个中心或微服务模块如何划分和定义，每个微服务模块应该暴露哪些接口服务能力。
组装服务：
上层应用应该如何去消费这些服务，应该如何根据业务去组合和组装这些服务。
中台最终提供可共享，可重用的能力中心，而前台则是去使用和消费这个能力。
中台和前台，更加中间的这个能力服务层，实现了高度松耦合特征。
正是这种松耦合，实现了高效，敏捷和灵活性。
二、中台划分
如今大中台模式不再拘泥于电商行业，随着发展和演变逐渐走向集团型、大型企业，为整个集团提供运营数据能力、技术能力、支撑能力、产品能力等，这时对于大中台的运用与划分也不再只是技术中台，还包括基础中台、数据中台、业务中台共同构成。
1. 基础中台
基础中台为大中台模式的底层基础支撑，也称之为PaaS容器层，而对于中台模式来说，要求平台灵活高效，这就意味着对容器集群管理与容器云平台的选择十分重要，技术运用的是否到位直接影响平台的开发效率和运维程度，在这方面目前Docker和K8S独占鳌头，同时对应的DevOPS与CI/CD理念也随着兴起。
敏捷开发和DevOps都是为了更好更快的发布产品而提出的一种理念，而CI/CD是实现这两者理念的一种方法，即持续集成、持续交付。
这些理念、工具、方法论作为基础中台组成部分来支撑中台模式。
2. 技术中台
中台技术不是空穴来风，是随着平台化架构的发展所演进的产物，从技术层面来讲，大中台技术延续平台化架构的高聚合、松耦合、数据高可用、资源易集成等特性，之后结合微服务方式，将企业核心业务下沉至基础设施中，基于前后端分离的模式，为企业打造一个连接一切、集成一切的共享平台，技术中台架构如下：
从技术中台架构中可以看出，底层为应用提供层，即企业信息化系统或伙伴客户相关信息化系统等；上层为集成PaaS层，将服务总线、数据总线、身份管理、门户平台等中间件产品和技术融入，做为技术支撑；DaaS数据层通过数据中台，结合主数据、大数据等技术，发挥数据治理、数据计算、配置分析的能力，服务中台层与共享服务层共同支持应用层中的行业业务，为用户提供个性化的服务。
3. 数据中台
随着数字化时代到来，互联网、云计算、大数据、人工智能等技术推动着传统企业的数字化转型，未来企业对人、事、物的管理必定会被数字化全面替代，在数据中台部分，帮助企业进行数据管理，打造数字化运营能力。
数据中台中不仅包括对业务数据的治理，还包括对海量数据的采集、存储、计算、配置、展现等一系列手段，数据中台架构如下：
从下至上可以看出，主要从系统、社交、网络等渠道采集结构化或半结构、非结构化数据，按照所需的业态选择不同技术手段接入数据，之后将数据存入到相应的数据库中进行处理，通过主数据治理清理脏数据，保证所需数据的一致性、准确性、完整性，之后将数据抽取或分发至计算平台中，通过不同的分析手段根据业务板块、主题进行多维度分析、加工处理，之后得到有价值的数据用于展现，辅助决策分析。
4. 业务中台
技术中台从技术角度出发，数据中台从业务数据角度出发，业务中台站在企业全局角度出发，从整体战略、业务支撑、连接用户、业务创新等方面进行统筹规划，由基础中台、技术中台、数据中台联合支撑来建设业务中台，业务中台架构如下：
底层以PaaS为核心的互联网中台作为支撑，通常将开源的、外采的、内研的信息化系统、平台等作为基础的能力封装成核心技术层，通过系统整合、业务流程再造、数据治理分析等一系列活动为企业的业务提供支撑，形成特有的业务层，连接上下游伙伴、内外部客户、设备资源系统、建立平衡的生态环境，支撑业务的发展与创新。
5.应用架构-中台模块应该长什么样子？
这个是需要进一步阐述和讲清楚的问题，因为这个不讲清楚容易产生误解。
即在整体微服务架构化后的中台各个中心，类似产品中心，客户中心，计费中心等。
要意识到这里的中台仍然是一个完整的应用，而不仅仅是逻辑层，仅仅是接口服务能力暴露，当然也有特殊场景，但是大部分场景下各个中台的模块都是自带前端的，本身也是一个能够完成自内聚的一个业务模块。
比如说订单中心，这个中台模块既可以通过前端各类电商或APP应用通过接口导入订单，但是其本身也具备完整的订单管理功能。
是一个完整的应用。
正式这个原因，我们谈中台和前台，而不是谈中台和前端，对于前台而言同样的道理，也是一个完整的应用模块，这个应用模块仅仅是调用了中台层各个模块的接口服务能力而已。
而不仅仅是我们开发单个系统的时候说的前端开发，这样理解就有问题了。
这个前台，虽然很多基础能力不用自己提供，不用自己做了，但是仍然还有大量的业务规则和逻辑处理，还有基于这些业务逻辑处理带来的服务组装和组合，这些工作仍然要在前台模块来完成。
同时前台模块本身仍然也是自带自己对应的数据库，存储一些基础元数据和过程数据。
从大IT应用架构看，我们分层规划的中台和前台，都是独立的各个微服务应用模块，对应每个微服务模块一般都自带完整的数据库业务逻辑（或叫领域服务层）前端。
到了一个单独的微服务模块内部，这个时候你的业务逻辑层可以独立打包，你的前端开发可以独立打包，这个时候才是我们传统讲的比较多的前后端分离。
再和IT团队架构对应，对应各个微服务模块的开发对应的是团队分工，不同的微服务模块可以由不同的团队来完成，而对于微服务模块里面的各层开发则对应到团队里面的角色岗位分工，可以有专门的前端开发，DB开发和逻辑层和接口服务开发人员。
6.应用模式
就阿里平台与个体商家的关系而言，虽然互相为独立的主体，但因为业务之间存在的联系，一定程度上已经分不清彼此，对于阿里来说，“大中台，小前台”理念中的前台强调创新和灵活多变，包括云计算、大数据、零售电商、广告业务、物流配送、售后维护以及其它业务；中台强调协调和规划管控，为前台业务开展提供底层技术、数据等资源支撑，多为平台类体系产品，一般都是外购、开源、自研相结合、不同的企业比重不同。
三、中台能力
在SOA和微服务架构体系下，或者说我们在构建企业中台能力层的时候，一个关键点就是微服务模块的划分，包括划分的方法，划分的粒度。
今天就先谈下微服务模块的划分。
在IT应用架构规划大中台的概念下，实际上中台包括了技术中台和业务中台，对于技术中台重点是各个技术组件和技术服务能力的实现，而对于业务中台则主要包括了数据能力和业务规则处理能力的提供。
对于业务中台本身也是分层，包括了最基本的数据类中心和业务处理类中心。
数据类中心本身又包括了基础主数据类和核心共享业务单据类，比如我们看到的产品中心，用户中心，属于基础主数据类。
而对于订单中心，库存中心则属于业务共享数据类。
业务处理类则主要是进行核心业务功能和逻辑的处理，类似的包括了交易中心，结算中心，计费中心等，都可以看做是业务处理类的中台模块。
当然，业务处理类中台也包括关键的领域服务提供组件，即这类组件需要调用底层更多基础原子模块的核心接口能力，经常组合后再提供出整合的组合能力。
技术中台模块的划分-完全垂直彻底解耦
技术中台主要负责提供各类的技术服务能力，其中包括了消息，缓存，存储（内存，结构化和非结构化），文件，日志，通知，规则引擎，流程等各种通用的和业务无关的技术能力。
可以看到对于各种技术服务之间，本身没有任何的耦合性，完全是垂直独立，因此对于技术中台中的微服务模块划分粒度，完全可以一个技术服务一个微服务模块，完全独立管理和部署，相互之间没有任何影响。
技术中台属于我们传统的PaaS技术平台必须要管控和治理的一部分内容，对于技术服务的接入，消费和调用，日志等都需要在PaaS管控治理平台能够查询和监控。
业务中台模块的划分-围绕数据仍然是核心
注意这里的业务中台模块，就是一个独立的微服务模块，一个独立的有数据库，逻辑层到前端界面展现的小应用。
只是这个业务中台本身还将自己的关键能力以API接口服务的方式开放给前台应用调用。
业务中台模块划分粒度相当重要，粒度太细后期集成和管控都相当复杂，同时由于模块划分太细也容易引入更多前台应用开发带来的分布式事务处理场景。
而粒度太粗的话本身又无法起到独立自治，后期易于变更运维，本身灵活敏捷的作用。
如果说做互联网电商，由于有类似阿里等的成功实践，可能大家闭着眼都知道应该包括类似产品中心，库存中心，用户中心，订单中心，结算中心等各类的中台模块。
但是如果是全新的业务类型，或者说针对企业内部的管理信息化，究竟应该如何去划分中台。
1.基础主数据类模块划分
如果一个基础主数据就一个微服务模块，那么会导致我们的微服务模块的量极大，比如用户中心，组织中心，人员中心，客户中心，物料中心，供应商中心等。
那么这种划分方法在企业内信息化上并不太合理。
如果是按标准的主数据管理系统的业务模块划分，实际上它不是按照数据维度进行划分，一般我们说主数据系统会包括了元数据和数据对象管理，数据集成和调度，数据清理，流程引擎，数据内容管理等各个模块。
而无法真正体现出以数据为中心的思想。
因此对于基础主数据类微服务模块，最好的方式是按数据域进行拆分，比如对于用户，组织，岗位，人员等划分到一个人力域数据中心，对于供应链，物料编码，采购类别等划分到采购或供应链域微服务模块。
这样划分的好处就是既实现了一定程度上的模块拆分和松耦合，同时按域划分后，同一个域的基础主数据本身在一个数据库中进行管理，这些基础主数据本身可能存在一定的耦合关系，那么这些耦合关系的处理将不再需要提升到分布式事务层面去处理。
2.业务功能类模块划分
谈业务功能类模块的划分，实际上又回到我们在传统进行单个业务系统架构设计的时候如何进行组件划分这个话题。
如何划分组件，简单来说就是要高内聚和松耦合，确保每个组件尽可能的独立自治，组件和组件之间的干扰最小。
当时我们在做单系统的时候，往往对于组件划分考虑的并不彻底，就是说在代码层面确实划分了组件，组件也可以进行独立打包，但是对于各个组件仍然对应一个数据库。
那么我们就经常犯一个错误，即虽然在业务和逻辑层两个组件看似松耦合了，但是很多耦合性转变到了数据库层了。
举个简单的例子，数据库的一个关联查询很容易就实现了，但是涉及到关联的两个表，其核心Owner确是不同的两个组件模块。
所以对于上层的业务组件划分，本身原来我们也谈两个方法，这里拿采购管理系统举例。
①按大阶段划分，可以分为采购请购，采购订单，采购执行，采购绩效评估，供应商，物料等模块。
②按数据维度划分，可以划分招投标中心，采购中心，绩效中心，供应商中心，物料中心等。
不论是哪种方法，我们看到在进行微服务模块划分的时候，关键还是要把基础和共享数据找出来，然后才是去处理上层的业务。
再来考虑业务流程，业务规则处理等还需要单独设置哪些微服务模块。
即使是用方法一，我们也看到每个模块都一定有自己关键的主属Owner数据。
划分微服务模块，实际上相对关键的一个步骤就是拆分数据库的过程。
要把原来我们一个数据库的内容，拆分并对应到各个微服务模块上。
主属Owner，对该数据具备了完全的CRUD能力。
而其它模块更多的是单纯的数据导入或数据查询。
大中台更多的是体现其核心数据集中和共享能力，而不是业务流程和规则处理能力，因此更多的业务流程处理都应该归结到前台更加合适。
一个大中台的订单中心，可以和各种各样的前台微服务模块对接，不管是网页还是APP应用，不管是渠道，政企还是电商，但是最终都是将正式流程处理完成后生效的订单数据导入到订单中心。
然后订单中心再提供完整的订单能力开放。
主流微服务架构框架的使用
要注意到，对于传统企业IT转型微服务架构，即使原来单体的一个业务系统拆分为多个微服务模块，而实际上每个微服务模块的体量仍然相对来说还是很大。
就拿采购管理来说，一个招投标中心单独拆分处理，这个微服务模块本身就是一个完整的业务系统，而且规模不小。
那么在拆分到微服务模块后，各个微服务模块的实现，如采用SpringCloud框架来做。
这个本身没有任何问题，但是在这个微服务模块内部，仍然还涉及到划分不同的组件包的问题。
那么这些组件包之间就仍然存在接口调用，那么这些接口调用是否需要微服务架构中心的注册中心去管理？
这个是一个很现实的问题，在这点上我们的理解如下：
对于一个传统的单体应用，在拆分为多个微服务模块后，对于微服务模块内部可以用类似SpringBoot去开发，但是内部的接口调用不用走注册中心，直接通过内部API接口去调用即可。
因为一个微服务模块本身也不存在还需要进行拆分部署的问题。
而对于一个完整的单体应用，存在多个微服务模块，这些微服务模块之间存在接口调用，因此对于一个完整的单体应用，需要部署一套服务注册中心去统一管理接口。
再次，如果这个单体应用存在和外部其它单体应用间的接口交互和集成，比如单体应用内部存在多个个微服务模块都需要开放能力接口给外部调用。
那么这个单体应用微服务架构化后需要进一步启用微服务网关。
当然，即使没有和外部应用交互，但是前台存在网页，APP，智能电商或Pad多种展示端的时候，仍然存在独立部署微服务网关的必要。
那么对于一个企业在彻底进行微服务架构化后，可能涉及到上100个微服务模块，如何进行管理？
如果全部都采用一个注册中心和网关去管理，实际上存在的可靠性和性能风险将会很大。
企业在微服务架构实施过程中我们建议的方式仍然是进行分域管理，而分域的基础就是传统的单体应用的边界，即采购管理时候独立个一个域，财务管理是独立的一个域，每个域都有自己独立的微服务注册中心和微服务网关。
那么域和域之间的接口服务调用就存在需要到不同的网关中去跟踪和查询日志的问题。
基于该点，我们仍然推荐方式是，进一步采用SOA总线或轻量的ESB来实现多个微服务网关暴露的接口服务的集成和统一管理。
以方便进行跨越集成的时候，多个接口服务的运行监控。
即我们的服务治理管控本身也是分层的额，对于域内的由各个域的微服务架构管控体系自己完成，对于域外的由上层的SOA管控平台完成。
对于中台构建，实际上两个关键点，第一个就是划分微服务模块粒度，第二个就是在模块划分清楚后确定服务识别和定义的粒度。
底层数据库没有拆分，但是仍然用SpringCloud框架开发，可以拆分为多个JAR包，在这种模式下只能认为是一个微服务模块，而不是独立，因为其不存在独立自治能力。
我们看到很多上层开发采用SpringCloud框架，但是数据库仍然采用一个数据库的情况，再次说明，对于这种架构设计，不是标准意义上的微服务架构，没有做到彻底解耦。
面向资源，面向对象和领域驱动设计
对于HttpRest接口说的最多的就是面向资源的设计，对于资源有标准的HttpPut,Post,Delte,Get等操作。
因此你需要定义好相应的资源。
资源可以放在计算机上并体现为比特流的事物，可以是结构化的数据或对象集合，也可以是图片或文件流，这些都是可以处理和操作的资源。
面向资源和领域驱动本身部署一种新的软件工程设计方法，真正的方法只有传统的面向结构设计和面向对象设计两种。
因此对于面向资源本身可以面向传统结构化设计，也可以按面向对象设计。
当然最好的方式仍然是面向对象进行设计。
资源即实体，实体即对象，这个对象代表的是业务对象，有明确的业务含义，类似供应商，采购订单，产品，合同等。
同时这些对象本身存在关联和递进的层次结构，比如供应商有对应的联系人，有对应的银行账号。
产品可能有对应的维修记录等。
而这些业务对象正是我们在领域驱动设计时候经常会识别的领域对象，这个领域对象本身涉及到多个子类，是否归结到一个大的领域对象最关键的还是是否共属一个生命周期。
面向资源设计，完全可以采用面向领域设计方法，首先定义领域对象，将领域对象建模为对应的资源，然后再考虑看这个资源应该暴露哪些能力接口出来。
所以在微服务架构下，首先要了解清楚，一个核心是面向资源进行Rest接口能力设计，资源的识别和定义可以参考领域设计的思路进行，识别和定义领域对象，再转为资源定义。
接口服务的粗粒度是关键
如果我们不按上面的方法按领域对象方式来定义资源，那么我们最容易犯的错误就是将所有的数据库表对象都全部定义为一个个独立的资源，将这些资源的CRUD操作，全部暴露为Get,Put,Post和Delete接口方法。
那么这样暴露出来的HttpRest接口方法就全部是细粒度的接口。
这种方法很省事，一个模块有100张表，你只需要暴露100个接口，每个接口都含标准的上述操作就完事了。
但是这种接口服务识别和
升级会员 