传统IT架构转型，从云原生平台到微服务应用构建( 三 ) _架构

即业务系统开发人员是没法上这个管理平台的，那么如果业务系统需要查看注册接入了哪些服务，配置了哪些规则，具体服务调用实例和日志信息的时候，都无法提供这些能力，都需要进行定制化开发。而恰好这些当前开源API网关产品的痛点，可能就是定制化要给API网关的管理平台产品的优点。
也就是说当前API网关产品更多是面向已有微服务架构体系内的API能力对外开放需求来做的，而不是基于微服务架构体系里面多个业务系统，开发厂商间接口协同思路来做的。因此要将API网关产品转变为一个具备多系统集成能力的集成类产品，中间还有很多工作要做。
微服务实施配合研发过程和团队管理

文章插图

当一个大的应用拆分为多个微服务并分配给多个厂商开发时，整个组织团队管理，研发过程管理，相互协同集成就变得非常重要。
【传统IT架构转型，从云原生平台到微服务应用构建】举例来说，一个大的业务系统按微服务架构思路招标，比如一个供应链系统，招标的时候即按微服务模块划分思路拆分为了招投标管理，采购管理，供应商管理三个独立的技术标，后续三个开发商中标，每个开发商开发时候都采用微服务架构，比如招投标管理里面会继续拆分微多个微服务模块，而这个时候我们看到就存在两类接口集成问题，在实际协同上需要采用不同的集成策略来处理。

招投标内部多个微服务组件间接口集成：同一厂商，采用服务注册和配置中心即可，不需要网关
招投标和采购管理两个大子系统间集成：不同厂商，需要采用API网关来完成集成和协同

而这些就是实际我们面对的业务场景，集成场景需要这样来做，当你真正做到现场的实施项目的时候，这些关键需求自然会碰到。但是你如果完全是研发驱动，脱离市场和一线客户需求，那么最终产品将出现很多关键功能性缺失。
那么当你无法在前期通过需求调研或竞品分析各种方式采集到完整的用户需求，并整理为产品需求的时候，你需要考虑的就是基于敏捷开发思路下的产品快速迭代。

文章插图

而快速迭代本身又有两个重点。

短周期：必须是短周期， 1周到4周，短周期目的就是真正让进度可视，可见，可验证。
可使用：可使用是一个关键点，即迭代发布的版本一定是可以发到现场让用户真正开始使用的版本。

任何迭代版本的发布，是否可用必须是一个关键的衡量敏捷项目管理和迭代质量的指标。举个例子来说，我们准备1个月发布V1.0初始迭代版本，但是发布后发现这个版本根本用不起来，我们又陆续发布了1.1 ， 1.2 ， 1.3三个小版本才真正用起来，而这三个小版本的发布可能又用了2个月的时间。也就是说你的产品真正用户开始使用，真正开始支撑业务用了3个月的时间。那么这种形式主义上的迭代没有任何意义。
通过迭代的方式是让你进一步的收集需求和优化改进，但是一定不是关键需求缺失导致产品根本无法使用。如果一个迭代版本无法使用，那么发布到现场本身也没有任何意义。
冠以敏捷而抛弃过程并导致混乱，太强调沟通而无法进行基础工件交付，开起来很美好的短周期产品发布但是却是一个无法真正用起来的半成品，这些都是伪敏捷的自欺欺人做法。