传统IT架构转型，从云原生平台到微服务应用构建
前面谈过很多关于数字化转型，云原生，微服务方面的文章。
虽然自己一直做大集团的SOA集成平台咨询规划和建设项目，但是当前传统企业数字化转型，国产化和自主可控，云原生，微服务是不可逆的技术发展趋势。
企业IT架构转型，不只是单体应用简单拆分为微服务这么简单。而是整个IT应用架构模式发生巨大的变化，核心思想仍然是平台+应用的构建模式。
而这个平台也不是简单的IaaS平台或PaaS资源调度平台，而是当前主流说法的云原生技术中台。不仅仅提供容器云和容器资源编排调度，还得提供消息，缓存，数据库等各种技术服务能力，彻底实现从IT基础设施从资源层到逻辑层的抽象。
云原生技术中台-平台+微服务
在单体应用微服务化后，前期的软件研发和交付过程，后期的软件监控运维和治理能力都必须配套跟上。因此完整的云原生整体解决方案里面包括了DevOps持续集成和交付，微服务治理两块核心内容。
在当前云原生和微服务发展趋势下也可以看到，传统的SOA集成平台和ESB逐步会被API网关和能力开放平台所取代。而SOA治理也逐步变化为微服务治理。
虽然SpringCLoud框架体系里面已经有类似Zuul的网关组件，但是整个规划里面我们还是将API网关单列出来，因为整个API网关不仅仅应用于微服务架构体系和对外API接口暴露，更加重要的是将成为我们后续构建能力开放和服务能力聚合平台的一个关键集成平台。
整个云原生平台规划将围绕以下两点展开。
- 容器云平台和DevOps支撑
- 微服务全生命周期管理和能力开放
对微服务架构的支持和融合
在原来谈微服务架构的文章一直在强调，微服务架构不是简单的使用SpringCloud开发框架，更加不是简单的提供Rest API接口服务就是微服务架构。
更加重要的是微服务模块如何拆分，微服务API接口服务如何识别，粒度如何把控。其次更加重要的是微服务框架体系如何和DevOps支撑平台融合，如何和API网关集成融合，包括如何和后续的监控运维平台融合。这些都必须考虑清楚，才能够形成DevOps的基础能力平台。
在微服务架构实施过程中，需要有一系列的开发规范和技术标准也需要提供，包括模块的划分设计，API接口服务识别和定义，代码开发，测试，数据库拆分，安全，分布式事务处理，部署上线，监控，运维等，这些标准都必须定义清楚，否则整个微服务架构实施后由于模块拆分的更细，没有很好的研发过程管控，技术标准约束你反而会觉得比原来单体应用开发更乱。
PaaS技术服务平台构建
在原来谈私有云PaaS平台的时候就经常谈到里面有一个技术平台提供类似4A，流程，安全，缓存，消息，日志等各种技术服务能力。而在整个微服务架构体系实施中，也必须有一个完整的技术平台，每一个技术服务就是一个独立的微服务组件模块，可以独立部署和管控。
技术平台的各种技术能力，仍然是以独立的技术服务方式提供给整个微服务架构体系中。在整个微服务架构体系里面可以看到，内部的各个业务微服务模块调用技术服务API接口就不需要通过API网关，而直接走微服务注册中心即可。
监控平台-端到端的监控能力
对于监控平台可以看到，需要提供从资源到服务再到应用的端到端监控能力。最底层是服务器，数据库，中间件等资源监控。上面是服务和服务链监控，再上面是应用监控和端到端业务流程监控。
资源，服务，应用三个层面的应用之间本身又相互影响，存在勾稽关系，一个是资源最终暴露的性能问题可以反追溯到具体的应用业务功能功能，而具体的业务流程端到端监控本身又可以详细分析到某一个业务功能点和接口服务的性能数据。
微服务治理
微服务治理概括来说，实际上关键包括两个部分。
- 其一是微服务应该如何拆分，API接口如何设计
- 其二是运行期如何监控，管理，运维
上图给出的围绕微服务全生命周期管理和基于服务度量体系的持续运维监控两个方面展开，对于一些二级的内容在该图暂时无法展开，比如常说的服务版本管理，服务依赖分析也是微服务治理的关键内容，暂时在该图没有体现。
在运行期还有一个关键思维的转变就是不是简单的发生问题故障后的运维治理，而是应该基于监控预警分析下的主动的技术运营和SLA服务等级提升。
如果你要去给别人做微服务治理，实际上是客户在确定了微服务架构后就需要介入，包括选择什么样的开发框架，采用哪些开源技术，这些开源技术如何整合，微服务如何拆分，微服务开发过程如何规范化，如何持续集成和部署，API接口如何设计，微服务间如何集成，运行期微服务如何进行状态和性能监控，如何进行安全，日志，限流等管控。
能力是开放平台-大生态建设的基础
构建微服务开放框架，DevOps能力支撑平台或API网关可以实现的内部完整的微服务架构化，而如果要做到对外运营，服务聚合和大生态体系建设，更加重要的就是能力开放平台的建设，这个平台最终实现内部能力的开放，外围能力和生态的聚合，并走向产品化+运营化的发展方向。
能力开放在前面我谈到过，一个是完全自身已有能力的开放，一个是构建开放平台聚合外围能力。而只有聚合外部能力才是构建大生态，可持续发展的关键。能力开放也不是简单接入一个API接口，更加重要的是提供从能力开发接入，能力运行，能力消费订购，能力监控运维的全生命周期管理能力。
基于云原生平台的开发和集成
传统企业IT架构转型过程中可以看到几个关键点的变化：
- 传统的单体应用-》独立自治的多个微服务模块
- 传统的PaaS平台+ESB服务总线基础-》DevOps+容器化PaaS+API网关
简单来说就是你要做好IT架构的微服务化，中台化转型，那么你支撑平台这件事情也得跟上，平台提供共性能力支撑和能力开放，支持多个微服务模块持续集成和交付。在后期监控运维还得配合DevOps理念跟上，形成要给完整的IT生命周期闭环管理。
在进行API网关和DevOps支撑平台研发的时候，自己一直在思考两个重点，就是业务驱动和快速迭代，即基于实际的业务使用场景来思考和提炼产品应该具备哪些功能，实际的功能优先级是如何的。而业务场景驱动里面最重要的就是最终的用户角色分析，不同的用户角色实际的问题和需求是如何的。
底层平台如何提供管控治理能力和易用性？
拿API网关来说，不论是SpringCLoud框架里面的Zuul微服务网关，还是类似Kong，Orange等开源API网关产品，最早可能只是一个具备代理和路由转发，具备基本的安全，流控能力的网关引擎，连基本的管理界面都没有，到现在类似Kong已经形成了基本的管理前台界面，能够方面的进行API注册接入，各类插件模块的配置和添加，但是最终的使用者是谁呢？
我们分析类似Kong网关产品最终的使用者是偏业务系统本身的开发人员的，而不是面向统一的业务系统集成商或平台能力提供商的。
先不说类似我们当前集成平台实施中提供的各种服务接入，服务订购等各种服务流程，就连最基本的业务系统视角的功能也很难独立提供。
即业务系统开发人员是没法上这个管理平台的，那么如果业务系统需要查看注册接入了哪些服务，配置了哪些规则，具体服务调用实例和日志信息的时候，都无法提供这些能力，都需要进行定制化开发。而恰好这些当前开源API网关产品的痛点，可能就是定制化要给API网关的管理平台产品的优点。
也就是说当前API网关产品更多是面向已有微服务架构体系内的API能力对外开放需求来做的，而不是基于微服务架构体系里面多个业务系统，开发厂商间接口协同思路来做的。因此要将API网关产品转变为一个具备多系统集成能力的集成类产品，中间还有很多工作要做。
微服务实施配合研发过程和团队管理
当一个大的应用拆分为多个微服务并分配给多个厂商开发时，整个组织团队管理，研发过程管理，相互协同集成就变得非常重要。
举例来说，一个大的业务系统按微服务架构思路招标，比如一个供应链系统，招标的时候即按微服务模块划分思路拆分为了招投标管理，采购管理，供应商管理三个独立的技术标，后续三个开发商中标，每个开发商开发时候都采用微服务架构，比如招投标管理里面会继续拆分微多个微服务模块，而这个时候我们看到就存在两类接口集成问题，在实际协同上需要采用不同的集成策略来处理。
- 招投标内部多个微服务组件间接口集成：同一厂商，采用服务注册和配置中心即可，不需要网关
- 招投标和采购管理两个大子系统间集成：不同厂商，需要采用API网关来完成集成和协同
而这些就是实际我们面对的业务场景，集成场景需要这样来做，当你真正做到现场的实施项目的时候，这些关键需求自然会碰到。但是你如果完全是研发驱动，脱离市场和一线客户需求，那么最终产品将出现很多关键功能性缺失。
那么当你无法在前期通过需求调研或竞品分析各种方式采集到完整的用户需求，并整理为产品需求的时候，你需要考虑的就是基于敏捷开发思路下的产品快速迭代。
而快速迭代本身又有两个重点。
- 短周期：必须是短周期，1周到4周，短周期目的就是真正让进度可视，可见，可验证。
- 可使用：可使用是一个关键点，即迭代发布的版本一定是可以发到现场让用户真正开始使用的版本。
任何迭代版本的发布，是否可用必须是一个关键的衡量敏捷项目管理和迭代质量的指标。举个例子来说，我们准备1个月发布V1.0初始迭代版本，但是发布后发现这个版本根本用不起来，我们又陆续发布了1.1，1.2，1.3三个小版本才真正用起来，而这三个小版本的发布可能又用了2个月的时间。也就是说你的产品真正用户开始使用，真正开始支撑业务用了3个月的时间。那么这种形式主义上的迭代没有任何意义。
通过迭代的方式是让你进一步的收集需求和优化改进，但是一定不是关键需求缺失导致产品根本无法使用。如果一个迭代版本无法使用，那么发布到现场本身也没有任何意义。
冠以敏捷而抛弃过程并导致混乱，太强调沟通而无法进行基础工件交付，开起来很美好的短周期产品发布但是却是一个无法真正用起来的半成品，这些都是伪敏捷的自欺欺人做法。
