KintoHub试用笔记
KintoHub能够管理云原生应用从源代码到线上环境部署的整个生命周期，包括构建、编排和部署。
KintoHub认为微服务必须遵从如下原则：
- 微服务的功能和数据构成界限上下文，微服务是单一职责的，其功能通过一个或多个API端点暴露
- 微服务必须支持通过上下文（contextual）API端点进行无限制的扩容
KintoHub会收集AP端点调用者的上下文信息，例如终端用户、应用程序、环境（Staging/Production...），每个API调用基于Kinto-App-Id和可选的会话内存（Session Memory）来追踪。合理的利用上下文信息，可以不必为每套环境部署专属服务，从而节约成本。这个理念让人觉得很难落地，让线上环境、测试环境在同一进程中运行风险太大。
要访问KintoHub API端点，首先需要进行身份验证。每个KintoApp都具有clientId/clientSecret作为凭证，使用此凭证你可以创建针对特定版本化环境的会话Token。从此Token中KintoHub可以知道你想和什么KintoBlocks进行交互。
共享内存的高级形式，通常基于Redis/Memcache。KintoHub支持通过报文头读写会话内存。试用这个功能会增强应用和KintoHub的耦合。
KintoHub希望消除编程语言差异带来的成本。和KintoHub交互、兼容，不需要通过语言特定的SDK，而只需要编写注释。
KintoHub利用APIDOC描述API规格，APIDOC本身是RESTful API的一种内联（和代码在一起）文档规范。比起流行的Swagger/OpenAPI，APIDOC更加简单、可以很容易的支持多种协议。KintoHub还允许在同一协议中基于HTTP或gRPC进行通信。
工作区是一个独立的空间，团队成员可以在工作区内协作，共享Deployments、KintoBlocks。你可以在KintoHub的仪表盘上创建新的工作区，并添加团队成员。
GitHub、Bitbucket的账号可以关联到工作区，这样工作区可以访问你的代码。
KintoBlock是自包含、容器化、语言无关、可组合、可共享的后端服务单元。目前支持的KintoBlock类型包括：
- Microservice：单一职责的微服务
- Website：从源码库直接家在、管理Web文集
- Custom Service：定义有状态应用，例如数据库、缓存、队列
未来会增加对Tasks、Functions的支持。
KintoBlock管理服务单元的完整生命周期，包括构建、组合、依赖管理、文档、CI/CD、部署以及扩容。
创建KintoBlock时，你需要指定它的编程语言+SDK版本、代码仓库、通信协议（目前支持gRPC/HTTP），此外你可以定制KintoBlock的构建、运行命令，设置暴露给KintoBlock的环境变量及其默认值。
创建KintoBlock后，首次构建会立即触发。默认情况下，每当master分支上有新的commit都会触发构建。
通过查看构建日志可以发现，KintoBlock做了以下工作：
- 签出代码
- 使用Docker的multi-stage机制执行构建：
- 第一stage的基础镜像取决于构建命令，构建出二进制文件
- 第二stage的基础镜像取决于编程语言+SDK版本，构建出运行时镜像
- 标记镜像并推送到镜像仓库asia.gcr.io
每次构建的结果，以列表的形式展示， 显示的字段包括BUILD id、Commit id、构建时间、构建日志、状态。支持Tag成功的构建，为其指定三段式（MAJOR.MINOR.REVISION）的版本号
目前看来，构建过程的可定制性较差，例如：
- Maven仓库无法使用私有服务，而且不支持Maven镜像缓存，每次构建都引起大量的外网流量
- 不支持指定JVM的实现，只能使用OpenJDK
环境变量能够让Deployment在多套环境下无缝切换，你可以在KintoBlock、Deployment的配置页面上进行设置环境变量。
Deployment是由KintoBlock编排成的、具有独特配置参数的应用程序。Deployment以Serverless的方式部署，也就是说，仅仅在被调用时才会动态加载、创建端点。
创建Deployment时，你需要指定其所属的Enviroment，其包含的KintoBlock及其版本，每个Deployment可以包含多个KintoBlock。并可以指定当KintoBlock的当前分支提交代码后是否自动部署。
你可以为Deployment中的每个KintoBlock覆盖环境的默认值。
你可以在多套环境下运行Deployment，让程序从Dev逐步晋升到Stg、Pdt环境，从而进行更加完整的测试，避免将缺陷暴露给用户。
使用晋升（Promoting）可以方便的将一个环境中的特性推送到另一个。 晋升就是将环境A的版本也部署到环境B上。
晋升这种设计之前在Jenkins X中了解过，Jenkins X甚至支持自动晋升。
KintoHub支持将Deployment回退到之前的某个版本。
要访问你的KintoBlock提供的服务，首先需要根据ClientID/ClientSecret来获取一个Token，然后通过页面指定的URL即可访问。
不论是外部还是内部访问，Endpoint的名称都是必须的，不过试用时无法获取端点列表。端点列表应该是根据APIDOC生成的，手工提取APIDOC中的端点拼装URL访问，报502错误。
Leave a Reply