产品规划和发展思路04(1.3)

在上面的架构图里面可以看到，实际上整个平台包括两个大的部分，一个是DevOps支撑平台，一个是API能力开放平台（包括了API网关）。而两个平台的开发和运行本身又是基于微服务架构开发框架和模式进行。因此在实际的产品规划和发展中，重心仍然是围绕以上两个平台展开。

API能力开放平台

这个在原来博客文章里面已经谈到，整个思路还是基于Kong网关进行二次开发和定制，远期规划思路是基于Go语言来完全自主实现API网关。

对于API能力开放平台，简单来说底层是Kong的API网关，中间是API管控治理平台实现API全生命周期管理能力，上层为API运营平台。其中API全生命周期管理平台又包括了API的开发和快速接入，发布平台；API的实际管控治理平台，API的运行监控，运维平台。

对于Kong网关的实际定制开发，主要是加强网关的安全，日志，限流熔断，服务接入消费自服务，权限隔离几个方面的关键能力。实际上我们看到Kong网关本身的协议转化适配，数据映射等能力是偏弱的，那在使用Kong网关接入的时候还是需要进一步增加协议转换适配方面的能力。

简单来说Kong网关可以统一发布Http Rest API的接口服务。

但是我们需要在Kong网关上增加相应的协议转换类插件来支撑遗留的接口快速发布，其中主要包括了将数据库标或SQL直接发布为Rest接口，将传统的SOAP WS直接发布为Rest API接口，将JMS消息适配后发布为Http Rest接口。支持这几种后基本可以满足我们日常大部分需求。

其次，需要增强基于Kong网关的管控治理能力，其中包括了我们常见的服务授权，安全配置，日志查看，限流配置，服务快速接入等。同时也包括了服务运行监控部分，对于服务运行监控完全可以参考我们当前ESB总线的思路来进行实现接口。

对于是否有配合Kong网关使用的服务链监控工具，限流熔断工具，需要进一步研究。

最后，对于API能力运营平台，这个优先级应该比较低，我们的重点还是优先放在平台层能力，管控能力的完善，然后再来考虑服务运营方面能力的完善。服务本身也是商品，因此服务运营平台的底层核心逻辑仍然是电商平台的核心模型，这是我们可以参考和借鉴的地方。

DevOps支撑平台和容器化PaaS平台

不管是API能力开放平台还是API网关，可以看到实际上并没有想象的容易推广。这主要有几个方面的原因，其一是很多企业还再传统IT架构下没有转型，本身就没有场景用到API网关；其二是企业虽然用到微服务架构或Rest API接口，但是业务量小接口少，没有到需要对接口进行统一管控治理的程度；其三就是对于大型一点的企业一般有自己的独立开发团队，开发团队能够进行微服务架构转型，自然也能够采用开源的API网关自己进行定制，而不需要再单独购买服务。

因此API网关的推广策略不是简单推广一个工具平台，而是需要配合我们微服务架构咨询，IT架构转型咨询一起推广实施才真正有效果。

另外一个推广策略就是API网关做为我们整个DevOps支撑平台整体解决方案里面的一个子系统，然后整体面向大型企业客户，大型开发团队进行推广实施，形成一个相互配合的完整解决方案。

对于DevOps支撑平台实际上要完善的地方很多，在这里我还是把他划分为几个大的部分。

1. 研发过程管理

2. 持续集成和交付平台

3. API网关

4. 容器化PaaS平台+其它技术服务类平台

5. 运维监控平台

在研发过程管理中主要是参考Scrum敏捷方法论的思路来实现以需求和用户故事为主线的整个研发生命周期管理，认为跟踪和监控，实现完整需求闭环和团队协同管理。在持续集成和交付平台，重点提示测试管理能力，或者你可以理解为这里需要一个完整的测试平台，覆盖测试用例，数据管理，测试执行，测试结果分析全生命周期管理能力。其次是技术服务类平台，这个各个企业有差异，但是我们需要支持这种标准能力接入和管理。

对于运维监控平台一直是需要整合和完善的地方，这里的运维包括了自动化运维流程标准的完善，运维流程和持续集成过程的协同；这里的监控包括了资源监控和服务监控，日志监控查询多个方面，而服务监控的重点又在服务链监控上面。

企业全面上云和朝云端迁移将成为趋势

首先我们来看下最近几年的一个关键概念云原生，美国专注于云计算与大数据基础平台的公司Pivotal最先提出了云原生应用，后来由谷歌成立的云原生计算基金会（CNCF，全称Cloud Native Computing Foundation）对云原生应用进行了定义，即：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术让工程师能够轻松地对系统作出频繁和可预测的重大变更。

简单来说，云原生可以从字面涵义来理解，指的是任何在云中诞生、或主要在云中设计并运行的事物。但云原生不只是指应用程序所在的位置，更多的是指应用程序的的构建和部署方式。

我们可以看下企业软件开发的一个发展阶段，简单点梳理可以为：

1. 企业的应用软件开发，设计，环境运行全部在公司内部私有云环境和数据中心

2. 软件开发，设计，测试等在企业内部，但是最终部署在公有云环境运行

3. 软件的开发，设计，测试，整个构建和部署，持续集成过程全部在公有云环境进行

到了第二阶段企业不用购买生产环境服务器资源，到了第三阶段企业应该不再购买任何的服务器资源，所有的开发，测试，生产全部迁移到云环境进行。对于完全轻资产运作的企业往往可以完全采用全云化的思路，而对于生产制造类型的企业类似ERP和MES等大型系统不适合全部迁移到云端，但是完全可以采用混合云的架构模式。

云原生的核心目标是将企业IT应用和IT基础设施的部署变得更加敏捷，从而使企业能够采用较低的技术成本享受到云的弹性和灵活性。根据云原生计算基金会(CNCF)的最初定义，云原生包括了：容器化封装+自动化管理+面向微服务。到了2018年，CNCF又将服务网格(Service Mesh)和声明式API给加了进来。具体而言，容器技术，服务网格，微服务和Serverless是云原生的核心技术，而DevOps是对这些技术进行整合的一个关键实践。

而云原生的关键优势主要包括：

1. 与传统的单体应用程序相比，由于使用敏捷和DevOps流程进行迭代式改进，加快了产品服务的上市

2. 微服务架构下可以自动地逐步改进云原生应用程序，以不断添加新功能或者改进原有功能。

3. 可以非侵入式地进行改进，不会造成停机或中断服务，给用户造成不良体验。

4. 支持云原生应用程序的基础架构弹性良好，可以轻松进行拓展或缩小规模。

5. 云原生开发流程可以更好地适应当今业务环境所需的速度和创新。

具体参考： https://www.secpulse.com/archives/118893.html

因此我们看到企业全面上云和朝云端迁移将成为趋势，而这里面云原生的优势也会逐步体现出来，而整个迁移和转型里面恰好也是我们当前重点在建设和研发的微服务架构，DevOps支撑平台。