产品规划思考点滴总结

　　今天对围绕SOA，云原生，DevOps等相关产品规划的内容做下思考总结。如果看过我前面的文章，也基本可以了解到当前我们整体是围绕云原生解决方案提供来规划和实现相应的技术产品和组件。这里面核心还是微服务开发框架和环境，DevOps，容器云，API网关和能力开放平台，监控运维平台等。传统ESB总线产品和API网关
　　今天再次对整个产品规划体系进行了重新思考，也明确了整体的产品架构和后续关键产品研发路线。在我博客上面原来重心也一直围绕ESB服务总线再谈，虽然有不少文章也谈到了API网关，OpenAPI能力开放平台，微服务架构，但是都没太详细展开，今天对这些内容再做一次梳理。
　　ESB服务总线和API网关
　　注意这两个实际上是一个层面的东西，如果SOA和微服务架构是一个层面，那么ESB总线和API网关就是另外一个对等层面，只是ESB总线更加重，支持传统异构系统协议转换，适配，数据映射等复杂能力。而API网关更加轻量，重点就是通过代理实现内外网隔离，其次就是各种安全，日志，流控拦截。
　　引擎和管理平台要拆分开
　　这个在很早一起进行的SOA和ESB产品规划的时候，我们就做到这一点，即ESB引擎要和ESB的管控治理平台拆分开，ESB可以多多种方式，类似OracleOSB，KongAPI网关，我们自研的ESB都属于ESB引擎的范畴。而基于引擎我们会建上层的管理平台，这个管理平台要做到能够兼容下面各种不同的引擎，前期我们规划也按该思路展开进行。
　　管理平台再进行二次拆分
　　对于管理平台需要再进行二次拆分，即涉及到本身接口管理的内容，包括接口服务注册，接入，安全配置等内容，这些内容和引擎绑定的很紧密，管理平台有时候并不容易做到多引擎适配。另外一部分就是完全的服务统计，监控运行分析内容，这部分内容我们完全是基于服务运行实例日志表展开，那么只要服务实例表是一套，我们的运行统计分析平台就可以做到完全复用一套。
　　基于以上思考，我们在传统ESB总线产品规划基础上就开始考虑增加API网关子产品，API网关产品不是简单的基于已有的自研ESB产品进行改造升级，而是基于当前主流的开源API网关产品，类似Kong网关进行定制开发和扩展，从当前趋势也可以看到在微服务架构推广实施下，Kong网关很可能成为一个主流的API网关产品。
　　因此需要考虑基于当前新架构重新扩展一套API网关产品，API网关本身和已有ESB产品是一种平级的引擎，只是一个轻一个重而已。关键的功能实现实际上都一样。
　　基于API网关产品，我们进行上下左右扩展，这些扩展围绕API网关进行。
　　在底层，我们扩展和当前我们已有的DevOps支撑平台的集成，即任何一个微服务模块的开发不仅仅涉及到微服务组件模块，也涉及到微服务组件暴露的API接口服务，引擎API接口服务的全生命周期也可以用DevOps支撑平台完全管理起来。
　　在左边，也就是API运行的全生命周期，扩展API接口服务开发接入平台，方便API接口服务的快速开发和接入，类似传统PaaS平台规划的时候我们做的开发框架和环境，开发平台提供。整个开发接入平台，实现API接口服务的快速注册接入，接口服务的入库过程。
　　服务接入后运行在API网关引擎，在右边即管理后生命周期，包括了API接口服务的后期治理管控，运行统计分析，运行监控，监控预警，服务链监控，服务SLA等，都属于后生命周期内容。
　　在上层我们扩展OpenAPI能力开放平台，实现API接口服务的能力开放，OpenAPI能力开放平台跟当前主流的京东，天猫的电商能力开放平台很类似，即需要提供面向API接口服务的运营能力，实际上我们完全可以理解OpenAPI能力开放平台需要包括自服务流程，服务订购，服务计量计费等能力，即一个基本电商平台的变形。
　　围绕中间件和技术平台这块，给出还是以微服务架构DevOps支撑平台容器PaaS为核心，其中将API网关从原有的架构体系中剥离出来，即API网关即可以做为整个DevOps支撑平台一部分，也可以作为独立提供的中间件集成产品。
　　同时原有思路为在已有的ESB总线引擎基础上进行改进，形成面向API接口开发，服务接入的API网关产品，即在ESB总线引擎基础上实现API全生命周期管理，形成API网关子产品。而新的思路为基于类似Kong网关重新开发和定制高效，轻量的API网关产品。
　　这个API网关和ESB总线都属于SOA集成中间件。ESB总线面向传统遗留系统较多，适配和协议转换场景复杂的企业应用集成场景。API网关产品面向当前新微服务架构下的API接口服务集成和管控
　　同时在我们整个产品体系规划中，为了实现产品的灵活组合，进一步对原有产品按微服务架构和组件化思路进行拆分，形成多个松耦合的子产品，可以基于用户需求灵魂组装我们提供的产品组合。
　　在原来谈ESB的时候，我们已经做了第一个层面的解耦设计，即将ESB产品分为三个子产品和组件，即ESB开发设计器，ESB总线引擎，ESB管控治理平台三部分内容，三者属于松耦合关系。
　　在上篇文章里面我们已经谈到，ESB管控治理平台实际包括两个部分内容，一个是对接口全生命周期管理的内容，一个是接口实例运行的监控分析内容。当我们规划ESB和API网关两个引擎的时候可以看到，对于管理平台部分两个引擎差异较大，往往并不容易复用一套管理平台，因此我们将管理平台部分进行拆分，将可复用的服务监控分析平台剥离出来，而对于管理平台部分仍然保留API网关和ESB总线各自一套的做法。
　　OpenAPI平台核心是已有接口能力的对外开放
　　对于OpenAPI平台我们进一步单列，我们理解是ESB总线接口，API网关的接口都可以提供给OpenAPI平台进行能力开放和对外运营。因此OpenAPI平台更多是一个接口服务的运营平台，那么这个平台就必须提供自服务门户，服务目录浏览，服务消费帮助指南，服务订购，服务计费计量，售后问题管理，多租户管理等一系列功能模块。
　　由于服务本身也是一种产品，因此一个可运营的OpenAPI平台需要提供类似主流电商平台一样的标准功能模块。我们的OpenAPI平台也一样，完全可以基于我们已有的电商平台进行改造和重构，而不是重头开发。
　　OpenAPI平台本身就是一个服务聚合后的能力开放平台，那么如果企业内部有两套总线，也完全可以将各自的API接口能力全部聚合到OpenAPI平台再进行开放和后续管理。这个时候我们看到，为了实现后续的订购服务开通，计量计费管理功能，OpenAPI平台应该和ESB或API网关引擎之间定义标准的接口集成，即两套引擎使用一套标准的接口进行集成。
　　管控平台中的自服务流程本身需要迁移到OpenAPI平台
　　进一步思考可以看到，对于原来我们规划在管控平台中的类似服务接入流程，服务订购流程等，需要迁移到OpenAPI平台中，作为面向业务系统的自服务流程。如果是建立的一个大生态，还可以看到，我们原来规划的API开发接入平台等内容也需要迁移到OpenAPI平台，做为业务系统自助化服务接入的一部分。即API接口的开发商不再是企业或运营方内部，而是变化为外围生态的业务合作伙伴。
　　自助化的服务接入自助化的服务订购服务运营能力才形成一个完整的能力开放平台。产品组合和产品规划
　　不要单纯的按个人的假设去构想产品，实际上你会发现很多产品构想的很美好，但是却并没有真正的市场或客户需求，或者说你规划产品的时候想到的用户需求都不是真正的刚需，仅仅是一种看上去很美好的伪需求。做产品的人有时候经常会碰到一个很熟悉的场景，就是你准备创业做个什么产品的时候，你跟身边的朋友讲，朋友们都觉得不错，值得去做，但是真到了产品做出来，没有一个朋友愿意买单。
　　一个好的产品往往应该是具备通过短周期迭代进行自我造血的能力，而不是一直需要不断的研发成本投入孵化，不断的成本投入无盈利往往并不具备可持续性。而好的产品就是迭代版本1上线就能够有用户，同时通过种子用户需求反馈不断的推出新的迭代版本，在每一个迭代版本都具备了自我造血能力，或者简单来说就是在早期就具备了用户或流量资源的变现能力。
　　做产品规划，即使你是做一个产品，你也应该理解为实际上是一个产品集规划，在整个规划里面需要拆分不同的组件或模块，同时构建基础的产品平台。这样做的目的就是在做产品的过程中积累可复用的内容，积累可灵活组装的内容。
　　举例来说你做一个APP，即使这个项目失败了你会发现抽取的基础平台或数据模型还可以快速的应用到做其它业务场景应用。那么原来的研发成本投入就可以进一步产生价值和作用。
　　产品规划很多时候实际上是站在成功者的肩膀上来完成，既有模仿，更有超越。一个好的产品不是产品研发使用的技术上的超越，而是对于市场和用户真实需求，和你需要提供的产品或服务匹配模式上的超越。对市场的洞察，对用户真正需求的理解往往才是做出好产品的关键。
　　产品规划不是好的商业模式规划，但是产品规划本身又必须得和你准备的商业模式相结合，你才能够搞明白产品研发完成后实际产品的营销或运营的重点在哪里。如何通过商业模式和运营策划来进一步采集需求，并促进产品研发本身的发展和演进。
　　一个产品越是做的产品化和可配置化，往往底层模型就越复杂，同时性能也就越降低。即使这样你也很难真正满足所有用户不同场景下的业务需求。在当前情况下更好的策略一定不是追求100的产品化，而是应该底层核心产品化，其它上层可以灵活定制和可配置。比如80的产品化20的可配置化往往是更好的思路。构建云原生技术平台
　　最近的工作重点就是对年初的产品规划进行重新复盘，并对产品规划相关内容进行调整，给出后续产品研发目标和具体行动路线。因此会写一线产品规划思考方面的文章，主要还是帮助自己理清楚后续产品发展的思路，形成可以长期持续发展的产品演进路线。
　　经过最近的思考，比较明确的就是对于原有的ESB服务总线产品研发逐步朝API网关转型，同时搭建基于API网关的SOA服务治理和监控平台，同时构建更上层面向运营或开发商合作伙伴的能力开放平台。虽然SpringCLoud框架体系里面已经有类似Zuul的网关组件，但是整个规划里面我们还是将API网关单列出来，因为整个API网关不仅仅应用于微服务架构体系和对外API接口暴露，更加重要的是将成为我们后续构建能力开放和服务能力聚合平台的一个关键集成平台。即整个重点将围绕以下两点展开。1。DevOps支撑平台（提供容器化PaaS和持续集成能力）
　　2。API网关平台和能力开放（提供最终的API全生命周期管理和后续的服务能力运营能力）
　　对微服务架构的支持和融合
　　在原来谈微服务架构的文章一直在强调，微服务架构不是简单的使用SpringCloud开发框架，更加不是简单的提供RestAPI接口服务就是微服务架构。而更加重要的是微服务模块如何拆分，微服务API接口服务如何识别，粒度如何把控。其次更加重要的是微服务框架体系如何和DevOps支撑平台融合，如何和API网关集成融合，包括如何和后续的监控运维平台融合。这些都必须考虑清楚，才能够形成DevOps的基础能力平台。
　　同时在微服务架构实施过程中，我们有一系列的开发规范和技术标准也需要提供，包括模块的划分设计，API接口服务识别和定义，代码开发，测试，数据库拆分，安全，分布式事务处理，部署上线，监控，运维等，这些标准都必须定义清楚，否则整个微服务架构实施后由于模块拆分的更细，没有很好的研发过程管控，技术标准约束你反而会觉得比原来单体应用开发更乱。
　　技术平台构建大体系的另外一个关键内容
　　在原来谈私有云PaaS平台的时候就经常谈到里面有一个技术平台提供类似4A，流程，安全，缓存，消息，日志等各种技术服务能力。而在整个微服务架构体系实施中，也必须有一个完整的技术平台，每一个技术服务就是一个独立的微服务组件模块，可以独立部署和管控。
　　技术平台的各种技术能力，仍然是以独立的技术服务方式提供给整个微服务架构体系中。在整个微服务架构体系里面可以看到，内部的各个业务微服务模块调用技术服务API接口就不需要通过API网关，而直接走微服务注册中心即可。
　　监控平台需要提供的是端到端的监控能力
　　对于监控平台可以看到，需要提供从资源到服务再到应用的端到端监控能力。最底层是服务器，数据库，中间件等资源监控。上面是服务和服务链监控，再上面是应用监控和端到端业务流程监控。
　　资源，服务，应用三个层面的应用之间本身又相互影响，存在勾稽关系，一个是资源最终暴露的性能问题可以反追溯到具体的应用业务功能功能，而具体的业务流程端到端监控本身又可以详细分析到某一个业务功能点和接口服务的性能数据。
　　能力开放平台面向对外运营和大生态建设的基础
　　构建微服务开放框架，DevOps能力支撑平台或API网关可以实现的内部完整的微服务架构化，而如果要做到对外运营，服务聚合和大生态体系建设，更加重要的就是能力开放平台的建设，这个平台最终实现内部能力的开放，外围能力和生态的聚合，并走向产品化运营化的发展方向。
　　能力开放在前面我谈到过，一个是完全自身已有能力的开放，一个是构建开放平台聚合外围能力。而只有聚合外部能力才是构建大生态，可持续发展的关键。能力开放也不是简单接入一个API接口，更加重要的是提供从能力开发接入，能力运行，能力消费订购，能力监控运维的全生命周期管理能力。市场驱动研发
　　从项目到产品，从产品到运营，估计是大部分软件企业希望的发展轨迹，但是很多却只能一直停留在做项目阶段，或者说连做项目都算不上，只能做软件人力外包等事情。
　　拿我们自己来说，前几天对我们最近10年做的软件项目做了下梳理和统计，发现大大小小通过做项目形成的软件产品有20多个，而实际到现在还在不断的进行升级维护的不超过5个，其余的全部都没有具备可复制性，放在配置库的代码也没有了任何价值。
　　一个项目形成的软件应用如果后续不能剥离可复用组件，或者不能产品化复制，那么对于整个公司来说就没有任何有价值资产积累，对企业来说也无法形成可持续的盈利模式。这个也是我原来一直在强调的，企业不是赚每个员工人天报价的差价钱，而是应该赚钱产品大量复制的钱。
　　在IPD集成产品开发里面，我们经常会谈到一点就是市场驱动研发，市场和研发的紧密协同，而实际上对于大部分软件企业来说，只有销售和研发，中间缺少了关键的市场环节。如何来理解这个事情？
　　在市场环节时候，所有努力全部围绕在我们的核心目标和产品研发上展开，不会偏离。
　　即我们前期是根据市场需求调研，通过对市场需求的分析来规划我们的产品，制定产品研发迭代计划，其次就是我们产品研发出来后是市场配合我们去做市场推广和策划，重点就是推我们的目标企业和目标用户。
　　那么这样我们做的事情，研发的产品始终都会围绕我们的目标进行。如果市场环节确实，那就变成销售看到有项目机会就会去接，后续开发团队也很难真正围绕主体产品开展持续的研发投入。
　　而销售型项目方式你会发现，当接一个新的项目型订单，是定制开发方式时候，销售在说这个项目具备可复制性，可以进行产品化孵化，而实际上根本无法产品化。
　　这么多年下来，我们孵化成功的产品，或者说能够持续研发投入不断进行架构优化和功能迭代的产品最终只有两个，即一个是我们的自研ESB产品，一个是DevOps支撑平台，自研ESB我们做了快6年，而DevOps支撑平台我们也做了3年，不断的持续改进。从自研ESB到我最新的API网关产品，也是平滑的过渡。也正是这个原因，在最新产品规划里面，将DevOps平台API网关作为核心的产品进行规划并持续演进。
　　当我们陷入到项目化的泥坑的时候，实际上主要是两个方面的原因，一个就是本身的生存和现金流压力，其次就是无法抵住高利润的诱惑。但是对于很多项目型的项目，刚开始评估的高利润到最后反而成了亏本项目，需求范围的不确定，后期反复变更，验收的困难相信也是大部分软件企业都面临的问题。
　　产品规划的落地和研发过程管理
　　产品规划最终要落地，因此必须有后续的产品研发版本计划，如果从半年或1年的产品规划角度来看，需要有具体的大版本研发计划和小版本研发规划。大版本可能比较粗，而小版本则是需要细化到具体的需求项，周期也要控制在2到4周以内。以方便项目的监控和跟踪管理。
　　研发版本计划制定后，就有执行，就有跟踪监控，就有研发过程管理，而最近2年由于大部分在外面做项目，发现研发过程管理这块缺少还是比较多，即原来已有的标准化的研发过程很多都没有继续执行，很多过程资产也没有进一步积累，这个本身是一种关键确实。即使我们现在推DevOps支撑平台，也需要和我们的项目管理，和我们的研发过程管理，和研发支撑工具链紧密的集成。