注：今天的文章重点介绍了我们团队围绕SOA和云原生的规划咨询、产品研发和项目实施。我标题的文章大部分来自公司的实际产品研发和集团一线项目的实践经验总结。
今天写完这篇文章的时候，本来只是想围绕微服务和DevOps来写云原生解决方案，但是经过最近的一些思考，包括和客户的沟通，我再次发现很多企业往往不需要中间平台或者重大的微服务改造，只需要一个SOA集成平台来实现跨系统集成和业务服务能力共享。因此，今天的准备应该从SOA集成平台开始。
由于经常有朋友私信问我是不是自由职业，我会在这里回复我目前在深圳元星科技有限公司，有兴趣的可以浏览公司的网站。其次，我的工作经历也很简单。我面前其实有一篇文章，如下：
01-09:中兴，从软件开发和架构到项目经理和产品总经理。
09-现在：元星科技，公司副总经理、总架构师，负责云平台产品线。
中兴通讯担任产品总工程师时，我总结了一页PPT作为重点工作实践，即职业化的指导思想是HPPD高效的产品研发和项目运营。
在这篇报告中，我将从以下六个方面着手。
市场：市场驱动的研发
管道：项目和投资组合管理
产品：产品生命周期和集成产品开发
项目：CMMI软件工程项目管理
团队：团队管理和团队建设
绩效：绩效管理机制
同时，从明道、高超技巧和实践三个维度对以上六个方面的每一点进行了阐述。能够宣传道教很重要，不是道教。方法论和工具很重要，但要用道家思想来驾驭艺术。
详情请参考我发的一篇文章：
产品生命周期管理解决方案和高效产品开发
为什么我这么强调练习的重要性？
其实你在我的标题上看到的是很多实践后的经验总结，比如说谈软件工程和敏捷研发。我在中兴做项目经理，把项目从CMMI二级评估带到CMMI四级评估，差不多用了4年时间。当时4级评价的首席评估师给了5个优秀分，我负责三条独特的产品线和研发；d项目，包括四级的QPM量化项目管理。现在你可以通过网上搜索找到我当时写的实用文章，类似Scrum敏捷项目方法论，团队本身也一直在实践和优化。
今天的文章重点介绍了团队的一些核心产品和解决方案，供大家参考。之前经常收到私信咨询是做IT规划咨询，还是企业数字化转型和微服务转型规划咨询。对于这类项目，我给出的答案是看具体的项目分析。
简单来说，能做这种大规模IT规划咨询的团队和人员非常少，需要多年的业务、技术和管理方面的实践经验。包括我们公司在内，只有少数lgddt有这个能力。要做好这种咨询项目，必须部署有能力的人，但如果项目只是购买我们的个人和个人服务，对我们来说价值不大。如果IT是从咨询规划到IT项目建设，我们有兴趣，可以详细谈合作。
以及SOA和ESB服务总线。
首先要讲的是SOA集成平台和ESB服务总线。事实上，我们从2007年开始实施大集团的接口平台建设项目，2009年实施中国联通集团的SOA集成平台建设，17年实施中国移动的集中式SOA集成平台建设项目。
对于大型集团项目，我们一般使用国外的ESB服务总线产品。类似的集团项目一般使用Oracle SOA套件，然后基于这个套件定制开发SOA治理和控制平台。例如，在最近的大型项目中，我们采用了OSB作为业务服务总线，MFT用于文件大数据传输，Weblogic消息中间件用于消息服务集成等。
对于一般规模的项目，我们使用自己开发的ESB服务总线产品。
产品底层基于ServiceMix总线、Apache Camel、CXF、OSGI网关、ActiveMQ、Karaf-cell集群等开源产品。我们在引擎之上构建了一个SOA治理和控制平台。扩展了前端的可视化服务设计和安排，扩展了后端的服务生命周期管理和治理控制能力。
om=pc">同时在服务注册接入，协议适配上，我们支持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研发团队长期招人，地点广州和深圳。
具体产品介绍可以点击阅读原文获取详细信息。