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

资源，服务，应用三个层面的应用之间本身又相互影响，存在勾稽关系，一个是资源最终暴露的性能问题可以反追溯到具体的应用业务功能功能，而具体的业务流程端到端监控本身又可以详细分析到某一个业务功能点和接口服务的性能数据。
微服务治理

文章插图

微服务治理概括来说，实际上关键包括两个部分。

其一是微服务应该如何拆分， 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网关产品最终的使用者是偏业务系统本身的开发人员的，而不是面向统一的业务系统集成商或平台能力提供商的。
先不说类似我们当前集成平台实施中提供的各种服务接入，服务订购等各种服务流程，就连最基本的业务系统视角的功能也很难独立提供。