注：今天这篇文章重点是当前我们团队围绕SOA和云原生展开的规划咨询，产品研发和项目实施等工作，自己头条上文章内容大部分来源于公司实际的产品研发和集团大项目一线的项目实践经验总结。

当今天整理这篇文章的时候，本来只想写围绕微服务和DevOps的云原生解决方案，但是经过最近的一些思考，包括和客户的沟通，再次发现很多企业往往并不需要中台，也不需要做大的微服务改造，而是仅仅需要一个SOA集成平台实现跨系统集成和业务服务能力共享。因此今天准备还是先从SOA集成平台谈起。

由于经常有朋友私信问我是否是自由职业，在这里再统一回复下当前是在深圳市远行科技股份有限公司，感兴趣的可以浏览公司网站。其次自己工作经历也很简单，我前面实际有篇文章介绍过，如下：

01-09年：中兴通讯，从软件开发，架构，到项目经理，产品总经理

09-现在：远行科技，公司副总经理，总架构师，主管云平台产品线

在中兴通讯做产品总工阶段，我当时总结了一页PPT可以作为一个关键工作实践的总结，即职业化指导思想是HPPD高效产品研发和项目化运作。

在这个汇报材料里面我从如下6个方面展开

市场：市场驱动研发

管道：项目群和项目组合管理

产品：产品生命周期和集成产品研发

项目：项目管理，软件工程CMMI

团队：团队管理和团队建设

绩效：绩效管理机制

同时以上6方面内容中的每一点又从明道，优术，践行三个维度进行展开描述。人能弘道，非道弘人，方法论和工具很重要，但是要做到以道驭术。

详细内容可以参考我发过的一篇文章：

PLM产品生命周期解决方案和高效产品研发

我为何如此强调实践的重要性？

实际上你看到的我头条上的内容很多都是实践过后的经验总结，比如谈软件工程和敏捷研发，自己在中兴通讯做项目经理经理带项目一直从CMMI2级评估做到CMMI4级评估，花费了差不多4年多的时间。当时四级评估的主任评估师给出5个优秀点，我负责的产品线和研发项目独得3个，包括四级的QPM量化项目管理你现在到网上搜索还能够搜到我当时写的实践文章，类似Scrum敏捷项目方法论同样如此，团队本身就一直在实践和优化。

今天这篇文章重点还是介绍下团队的一些核心产品和解决方案，供大家参考。前面经常收到私信咨询是否做IT规划咨询，或企业数字化转型，微服务转型规划咨询。对于这类项目我给出的答案都是看具体项目分析。

简单来说就是能够做这种大型IT规划咨询的团队和人少之又少，这个需要业务，技术，管理多个方面的多年实践经验积累才行。包括我们公司也仅仅只有为数不多的核心骨干具备这个能力。这种咨询项目要做好必须配置有能力的人，但是如果项目仅仅是购买我们的人天服务，那实际对我们并没有多大的价值。如果本身是从咨询规划到IT项目建设落地，我们感兴趣，可以详细聊合作。

SOA和ESB服务总线

第一个要谈的就是SOA集成平台和ESB服务总线，实际上我们从07年开始就实施大型集团的的接口平台建设项目，在09年又实施联通集团的SOA集成平台建设，17年开始实施中国移动集中化SOA集成平台建设项目。

对于大型集团项目我们一般用国外的ESB服务总线产品，类似集团项目一般采用Oracle SOA套件的比较多，然后基于该套件定制研发SOA治理管控平台。比如在最近大项目中我们采用了OSB作为业务服务总线，MFT进行文件大数据传输，Weblogic消息中间件进行消息服务集成等。

而对于一般规模的项目我们用自主研发的ESB服务总线产品。

该产品底层基于ServiceMix总线，Apache Camel, CXF，OSGI网关，ActiveMQ，Karaf-Cellar集群等开源产品，我们在引擎之上构建SOA治理管控平台。扩展了前端的可视化服务设计编排，扩展了后端的服务全生命周期管理和治理管控能力。

同时在服务注册接入，协议适配上，我们支持SOAP ,Rest API，JMS主流协议之间的转换，服务可视化设计，服务代理，服务路由，数据库适配，消息适配，大数据集成，大文件集成等各种能力，并在多个实际项目中应用和验证。

一个完整的SOA架构体系实际内容相对多。

涉及到业务流程，数据，服务，集成，安全，管控，部署等多个方面的内容。在SOA项目建设实施中，我们还做SOA架构规划，SOA服务目录库规划相关咨询规划。

对于服务架构规划整体方法如下：

该规划方法我们在类似移动，TCL，唐人神，西安地铁等多个项目中验证并落地实践。是一套行之有效的可落地的方法论。

对于SOA规划咨询和SOA集成平台建设，虽然公司和产品团队在业界的名气比较小，但是不是弱在产品和团队，而是弱在市场能力上。选择我们的客户，不管是大型集团客户还是一般规划的企业客户，最终都会获得好评。

对于最近规划建设和实施的SOA集成平台项目，实际接入系统上1000个，每天的接口服务调用量峰值超过2000万次，分钟级并发量超过5万次，分钟级的数据传输量大于1G。整体项目从上线一来一直运行平稳。

简单来说国内有多少SOA厂商做过类似上面这种规模的项目？

这种项目的成功建设不是简单的卖一个产品，更加重要的就是实施能力，后续的治理管控能力，里面涉及到的高可用性架构涉及，大数据传输，接口服务限流熔断，接口安全等每个点展开都可以谈一篇文章。你只有真正做过你才知道，不是简单的看下产品手册或理论就能够解决的问题。

最后再简单总结下我们实施SOA的优势：

超过10年以上的大型SOA项目建设经验和方法论

既可以实施国外大型SOA产品也有自主研发ESB产品

完整的SOA咨询规划和SOA实施方法论积累

经过多年验证的SOA治理管控平台

微服务转型咨询和规划

第二个我想谈下微服务转型规划，这个里面实际涉及到的内容很多，也包括了类似中台建设规划，微服务架构规划，微服务划分和API接口识别，服务标准规范，服务治理管控体系建设等内容。

随着企业数字化转型的深入，企业传统IT架构转型，包括云原生等逐步将成为企业IT发展的一个趋势。当前对于大部分企业来说已经建设了自己的IT应用架构和系统，不是一片空白，如何最大化地保留企业内部已有的IT资产，并平滑切换到新的架构模式，支撑企业业务目标和战略的达成才是关键。

前几天我谈中台的时候就说到，不是中台思想不好，而是中台被很多开发商给玩死了。随便一个企业就推自己完整的中台建设方案，就对传统已有IT架构推翻，第一期建设就要投入上千万的费用，最终出来的东西还不一定能够敏捷支撑业务。那么这种中台建设，这种理想化的微服务架构化有何意义？

虽然我在前面写中台和微服务相关文章的时候也不断在强调咨询规划方法论和实施方法论，但是这些方法论绝对不可能凭空产生，而是需要你做过相关的项目和实践总结。

包括我整理这个方法论来源于哪里？

实际上来源于我们本身大型基于企业架构思想的集团信息化规划咨询项目实践，并和微服务架构改造优化实践两者的融合。最终给出一个可行的方法和思路。简单来说微服务架构规划本身仍然还是要依托SOA架构思想，云平台建设思想，领域建模，企业架构规划方法，否则就是无根之木。

但是现在乱象确实很多软件企业推自己的中台方法论和微服务规划咨询，本身自己也没做过什么大项目，人员也没有上面这些关键点经验，自身知识体系就不完善，实践经验也欠缺，导致客户满意度低。

不要看品牌，也不要听忽悠，找对正确的人帮你做正确的事才是关键。

在几年前我自己实施TCL集团的O2O垂直一体化自建电商平台项目的时候，在中间进行了SOA架构和服务目录规划，当前来看就是将内部已有的ERP，CRM，MES等核心系统的业务能力通过服务识别，将可复用的服务开发接入到SOA集成平台，做为电商平台的内部集成业务能力底座。这本质也是构建了一个对外的业务中台或能力中台，因此并不是说中台建设一定要微服务，一定要推翻重来。

对于该点详细分析可参考：

基于企业自建电商平台来思考中台和微服务架构演进

那么再说明下我们为何能做微服务架构规划咨询这件事。

首先就是我们本身就承接过大型集团型企业的IT架构规划，也作为类似SOA架构规划，数据治理规划等细分维度的规划咨询项目。就我自己前面出版过《企业私有云平台规划和建设》的专业书籍，本身书籍背景就是联通集团的PaaS平台建设大项目。

其次要做这个规划必须具备既懂企业核心业务价值链业务又懂技术的核心团队人员，这类人员实际上相对短缺，很多人不具备这种大架构规划的能力。这种架构规划不是说你PPT图画得多么漂亮，最终需要的真正指导落地实践。而我们团队刚好具备各个细分维度的专业人才，包括供应链，财务核心业务价值链，也包括类似SOA，主数据，数据治理，云平台规划建设方面的专业人员。

最后一点就是我们规划咨询总结的方法本身是经过实践验证可落地的，同时确保最大化的保留企业已有的遗留IT资产，考虑如何平滑迁移和过渡。包括我们自己的财务共享平台本身也进行了微服务架构改造和云原生迁移，这些都是通过实践证明可行的方法。

这件事情要出一个PPT解决方案很容易，但是要真正做好很不容易，需要的是真正有实践经验的团队，选择关键的人而非公司或品牌。

我们为何选择做咨询规划类项目？

简单来说就是这个事情需要核心团队才能够做好，这个核心团队基本都是公司核心管理层和产品线负责人，多年大项目经验积累。如果简单卖人头对我们毫无意义，如果是可持续的项目当然可以合作。

DevOps解决方案和技术中台

在17年当时云原生概念还是不是特别火的时候，我当时就给出了基于微服务和DevOps，容器云的思路来构建一个远行的PaaS云平台。

当时我推出了一个云梯计划。其重点就是协助传统企业IT架构转型，其中包括了基于企业私有云PaaS平台的平台+应用构建思路，也包括了最新的微服务架构和DevOps持续集成思想，其核心是协助企业研发过程改进和敏捷化转型，同时提供一种更加高度灵活，可复用，松耦合的架构体系支撑。

云梯计划是远行科技多年围绕SOA，云计算，微服务架构和容器化实践积累的经验总结，云梯计划将为企业提供完整的云化+微服务架构+DevOps完整落地解决方案，不仅仅是卖工具和产品，而是真正的有软件过程改进，架构设计经验的技术顾问和管理顾问提供全程的技术咨询服务帮助企业落地。

如上图，云梯本身又包括云台，云网，云镜三个子产品体系。

云台：提供平台层支撑能力，包括微服务框架，容器平台，DevOps支撑平台，4A+BPM等

云网：提供服务集成和服务能力开放能力，从重的ESB服务总线到轻量的微服务网关

云镜：提供微服务架构体系下的APM应用监控能力和BAM业务服务，服务链监控能力

现在来看，我们云网和云台的能力基本全部实现，而对于云镜这块仅仅对关键技术点完成研发，但是还没有形成一个完整独立的产品。同时对于开发框架和环境这块，我们围绕微服务架构开发和封装了低代码开发平台和核心技术组件的积累，并在公司自己项目做完验证。

基于最近几年的微服务规划建设和大项目实施，对我们自己的技术中台进一步进行了完善，给出了新的整体架构如下：

整体解决方案包括的产品和服务实际包括四块内容如下：

容器云平台

Docker容器和镜像管理

Kubernetes容器编排

DevOps支撑平台

敏捷研发中心

持续集成和持续交付

分布式配置中心

自动化测试中心

低代码开发平台

微服务开发框架

低代码开发-自定义表单，流程

技术中台服务

技术服务能力

API网关和能力开发

对于DevOps支撑平台实际是整个团队和产品线一个关键方向，从16年就开始持续研发投入，同时也承担了大型集团企业的DevOps建设和实施工作。

有的人可能会说DevOps不是很多企业都在做，都在实践吗，这个不就是大量开发工具集的集成吗？稍微有点开发能力就能够做。

确实，如果仅仅是要给开发团队实施DevOps很容易，对相关的开发工具进行整合，定制一些脚本代码往往就能够完成，但是要实现组织级的DevOps，并且完全实践DevOps能力成熟度模型没有几个企业能做到。

比如我们实践的DevOps平台支撑上1000个业务系统接入，17亿行代码，7万个部署包，2万个镜像，每天CI/CD次数3000多次，试问有多少当前做DevOps平台的企业能够达到这个规模。

你为了支撑如此大的规模和并发，你在DevOps平台设计的适合需要考虑多租户，底层模型，需要考虑底层的git库，编译构建环境，依赖库，镜像库全部实现能力分片和集群化，这个不是一般的DevOps平台能够做到的。

再比如我们前面谈到的流水线设计，需要支持多级流水线，需要能够灵活编排，需要实现流水线和敏捷研发管理之间的集成，这个也需要大量实践才能够完成。

DevOps平台不仅仅是实现研发运维一体化，实现持续集成和持续交付，更加重要的实现研发管理从目标到过程，实现关键管控节点的可视化，整个过程可控，研发资产可视化，逐步降低对开发厂商的依赖本身也是实施DevOps的一个重要收益。

其次对于DevOps的实施不仅仅是一个产品，一个工具集，更加重要的是基于敏捷思维的研发过程改进，这个需要的是做过CMMI和Scrum敏捷研发，对软件工程和软件生命周期有深入理解的咨询实施团队才能够完成。

公司云原生解决方案介绍可以参考：

企业中台规划咨询和微服务架构建设实施方案分享

对于DevOps平台是我们21年推广的一个重要内容，如果对这块感兴趣也欢迎给我私信留言进一步沟通交流。以上三部分内容靠PPT，靠理论是行不通的，更多的是需要实践验证，而我们团队的优势刚好在于实践上面。

最后打个小广告，对于SOA，DevOps方面感兴趣的开发人员，也欢迎私信我，我们DevOps研发团队长期招人，地点广州和深圳。

具体产品介绍可以点击阅读原文获取详细信息。