基于微服务架构下的容器化PaaS平台02
基于微服务架构下的容器化PaaS平台02
2018-05-11 09:44:20 来源：人月神话微博
抢沙发
2018-05-11 09:44:20 来源：人月神话微博
摘要：在一个企业构建完整的容器化PaaS平台的时候，实际上需要包括OpenAPI平台部分的能力。
关键词：
微服务架构
容器
PaaS
当进行企业内部多个微服务模块间的服务集成的时候，即使这些微服务模块都不朝外部互联网或APP应用暴露服务或能力开放，我们仍然需要微服务网关来实现这些接口服务的统一管理，其核心需要管理的内容仍然包括了服务注册，服务订购，服务安全，服务日志和运行监控，负载均衡，流量控制，服务代理等基础能力。
服务的注册和接入
在采用类似SpringCloud等微服务开发框架后，在开发一个微服务模块的时候，本身存在前端和后端分离的情况，即前端仍然需求通过接口来访问后端的能力。同时某个微服务模块还需要跨模块访问其它微服务模块提供的能力。在这种场景下，我们更加希望是在同一个微服务模块内部，不存在分布式或跨资源的问题，这种接口访问应该是一种更加轻量高效的模式，比如本地化的Java API接口。而在跨微服务模块访问的时候，再将这种本地的API接口转变为RPC接口或Http Rest服务接口。
因此在微服务模块进行服务注册的时候，除了直接注册可以远程访问的Http Rest接口服务能力外，我们希望能够直接对原生的Java API接口进行注册，同时将API接口发布为Http Rest服务。同时对于微服务模块在使用其它微服务模块的接口服务的时候，又可能像调用本地API接口一样进行使用。这个即是我前几天有篇文章谈的，将微服务网关实现为一种彻底去中心化的微服务网关，同时在PaaS平台镜像制作或容器化部署的时候自动下发本地的SDK服务代理包。
通过这种方式，可以彻底将多个微服务模块间通过Http Rest服务或SOAP服务进行协同的细节全部屏蔽。微服务模块所有的接口提供或接口使用操作都类似一种本地化的API操作，同时由于微服务网关本身去中心化后，服务网关只需要提供服务注册，服务订购，基础服务元数据配置信息维护等关键能力。其余的服务日志，安全，流控，包括负载均衡等能力全部可以下沉到本地的SDK代理包中完成，也减少了微服务网关成为中心化节点的可靠性，性能等诸多问题。
微服务架构下不存在复杂的可视化服务设计操作，也不存在类似传统ESB总线那样复杂的协议转换和数据映射，而是只需要提供较简单的服务设计，API接口服务注册和发布能力即可。一个服务在注册和接入后仍然需要提供在线的服务测试工具和功能。
在采用容器化管理模式下，对于Kubernates本身就有对容器化资源进行负载均衡的能力，也就是实际上我们接入到微服务网关的地址应该是从Kubernates负载后出来的地址。如果微服务网关本身也进行了集群化部署，这个时候微服务网关发布出来的地址是第二次负载均衡后的地址。当然，如果是在去中心化架构模式的下微服务网关，应该不存在微服务网关本身的集群化部署问题了。
服务订购和服务消费
注意整个注册的粒度是先应用注册，然后是微服务模块注册，然后才是微服务模块里面的接口服务能力注册，接口服务本身是由微服务模块提供出来的。对于接口服务的订购也是同样的道理，需要授权和管理到微服务模块级别，只有进行了服务订购才能够进行服务访问，同时对于微服务模块消费端都分配独立的Token令牌信息。对于Token的安全机制，既可以使用静态的Token，定时刷新；也可以使用每次接口服务调用都动态获取的动态令牌（会一定影响接口服务性能）。
服务订购成功后，消费端微服务模块同样可以利用在线的API接口服务测试工具对服务进行测试。同时服务订购成功后服务管控平台需要提供具体的服务访问地址信息，Token信息，服务访问说明信息等。如果是去中心化的微服务网关，这里需要实现如何将订购接口服务内容动态实时下发到本地SDK服务代理包中。
有A，B两个微服务模块，如果A模块要消费B模块提供的微服务接口服务能力，这个时候A模块本身不用关心B模块具体提供的接口服务地址，同时也不要关心微服务网关进行封装代理后的地址，而只需要访问服务注册库去获取地址信息，只不过这个地址信息可以缓存到本地而已。在这种场景下，A，B模块在部署的时候唯一需要确认的就是环境信息，即究竟是开发环境还是UAT测试环境，或者说生产环境，不同的环境即对应访问不同的服务地址信息。
服务日志和运行监控
接口服务调用日志查询是最基本的能力，这个需要在微服务网关或者说微服务治理平台提供。对于每一次接口服务调用，最好的就是需要实现能够根据服务实例号详细的查询到具体接口服务调用的输入，输出信息，包括出现错误后的详细异常日志信息。服务调用开发时间，结束时间信息等。当前微服务架构下谈的比较多的是服务链监控能力，这个当前也有不少的开源实现方案，在我博客文章中也有一篇文章专门谈了如果自己来实现一种最简单的服务链监控和跟踪。
服务运行统计分析是另外一个常用的功能，基本的统一原始仍然是服务运行次数，运行时间，数据量，异常数等。而实际的统计维度则包括了按服务，按服务类型，按应用，按微服务模块，按时间等各种统计维度。对于服务运行统计最好是实现一种灵活的自定义统计分析报表能力，开发者可以自己进行灵活的定制。实际的PaaS平台整体的监控包括了多个层次，最上层的是应用监控，然后是服务监控，最下面的则是资源监控，而资源监控本身又包括了中间件容器资源，虚拟机，物理服务器等多个层面。而我们实际的述求是从应用监控发现的问题能够实时的追溯到服务或资源，而从资源监控本身发现的预警又能够协助我们去反查潜在的问题应用模块。
服务的预警策略和预警与服务流量控制功能往往需要配合使用。即当触发了服务预警或告警的时候，才进行服务流量控制。这种告警可以是大并发的服务异常调用，大数据量的服务调用，还可以是这些大并发调用引起的CPU和内存消耗异常等。即一旦我们发现了影响到中间件资源稳定运行的接口服务，就需要对这个服务进行流控，或对服务进行降级或隔离，以避免单个服务影响到整个中间件容器的运行。
服务治理门户
服务治理门户应该包括在大的PaaS门户里面，重要的还是实现面向开发者的服务注册接入，服务消费订购，服务监控等各种自服务功能和能力。同时提供完整的服务目录，服务接入和服务订购说明，流程，规范，示例等。方面开发者快速的接入和消费服务。这块功能和当前类似京东，淘宝的OpenAPI平台很类似。在一个企业构建完整的容器化PaaS平台的时候，实际上需要包括OpenAPI平台部分的能力。
在谈SOA服务管控治理的时候，我们经常会谈到通过SOA咨询规划实现一个完整的SOA服务资产库和目录库，对于服务治理门户即可以提供这部门服务目录资产的完整查询，查看和访问能力。、即服务目录除了提供完整的接口服务目录列表外，还为服务消费者提供API功能简介、开发指南、API调用说明、返回码说明等文档。提供查看单条API的详细信息功能，用户可查看指定API的名称、调用路径、功能说明等信息，同时提供在线的接口服务测试。
第三十四届CIO班招生
北达软EXIN网络空间与IT安全基础认证培训
北达软EXIN DevOps Professional认证培训
责编：yangjun
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
