复盘AutoX微服务技术选型
前言：
去年12月份写过一篇博文《从一个简单需求学习微服务思想》，当时接到了一个需求任务要把企业内部运维栈和工具栈的系统全部管理起来，出于功能和性能扩展维度的考虑，选择用SpringCloud微服务架构来开发，命名为AutoX，到现在已经过去1年了，现在复盘下当时的选择，确实是条正确的道路。
原因有以下几点：
1 功能扩展
在过去一年内又不断接到了罗干新的需求，例如接入Jira的管理、有度的管理、邮件系统管理、报表系统管理等，都可以以松耦合的方式接入到AutoX中来。
2 单机资源不足
随着功能和用户的增加，去年申请的8核16G硬件资源吃紧，微服务架构可以很方面的通过添加机器的方式来解决性能问题，不需要关心代码。
3 容器云
今年Q3开始公司启用了kubernetes，AutoX只需要多准备一个DockerFile镜像文件就可以无缝入住k8s，服务节点交给容器云管理后如鱼得水，在保持SpringCloud服务发现、熔断降级、API路由、全链路追踪等原有功能的基础上，又获得了自动容缩、金丝雀发布、代码配置分离等新特性。
本篇博文把AutoX的设计思想分享给大家，希望对大家的实际工作有所帮助。
AutoX设计与功能说明
AutoX功能架构
功能架构图
功能架构详解
AutoX目前有4个服务中心，分别负责云平台调度、企业工具自动化集成、消息通知和报表，由于采用SpringCloud微服务架构设计，还具备自动发现、API网关、控制鉴权、降级熔断等功能，所有微服务节点均是无状态的，采用云平台弹性伸缩方式部署或者容器云方式部署便可以实现自动伸缩。
AutoX微服务架构
微服务拓扑图
微服务拓扑详解
ci-gateway是请求所有服务统一的API入口，统一采用Restful请求方式，API路由将会根据Restful请求中\{center\}和\{sub\}这两级内容的不同将请求转发到最终的服务节点上。ci-cloudcenter是云平台调度中心，本身不提供服务，根据\{sub\}进行服务转发。同理还有ci-toolcenter、ci-messcenter、ci-reportcenter.第三层服务节点（ci-alicloud、ci-tencent、ci-jiratool、ci-spinnaker、ci-youdu、ci-email、ci-release）是真正实现了处理业务的服务节点。辅助部分中ci-register也是个微服务节点，是整个微服务系统的注册中心。Secret、ConfigMap配合Manifest在容器云中对应用进行代码配置分离。利用DockerFile构造微服务镜像。
AutoX核心模块详解
ci-register模块
服务注册中心，具有自动发现、区域亲和、坏点自动剔除等功能。非容器环境下可以多节点互相注册组成高可用，容器云环境可以交给DeployMent或RS本身去保证可用性。
ci-gateway模块
API网关，具有路由分发、服务鉴权、访问黑白名单等功能。非容器环境下可以多节点注册到register中组成高可用，容器云环境可以交给DeployMent或RS本身。
ci-jiratool模块
负责Jira的子任务自动创建、环节节点通知、经办人自动分配、环节校验等功能。
ci-alicloud模块
负责对阿里云下发一系列串行操作任务，例如当弹性伸缩组内实例发生变化后自动更新伸缩组镜像。
ci-email模块
利用请求参数+邮件模板的方式，当接收到服务请求后先找到对应的邮件模板，进行参数模板合成后再进行发送。
左手的ㄟ右手
小灰灰
た 入场券
红太狼
╰+攻爆jí腚メ
我会带着你远行
「爱情、让人受尽委屈。」
还没有评论，来说两句吧...