自动驾驶模式(atuopilot pattern)
微服务架构:给企业提供了以各种管理复杂应用进程的工具.
容器:提供了一种新的管理微服务依赖和部署的方式.
自动驾驶模式:将应用重启,关闭,缩放和异常恢复等操作任务自动嵌入代码,实现服务连接人工操作最小化.
模式优点:
易部署和缩放
工具自动化,节省操作时间
自动在代码中嵌入操作任务,实现应用即文档(本身就解释了所有操作,天生具备可读性且不用专门维护)
保持自动嵌入代码,增加了流程可见性和参与总流程的机会,使开发更具有全局性
关键上,应用运行不依赖环境,本地和生产操作相同
自动驾驶模式使每个应用组件的生命周期自动化.不论应用架构是基于单容器分层还是微服务,每个容器里的应用都有自己的生命周期,拥有在生命周期内的一系列操作.这些组件应用(数据库,缓存,代理等)组成了一个完成了应用程序.
大多数自动驾驶模式实现是基于docker容器的,但这并不强制.模式的核心是要求开发和运维去考虑在应用的生命周期关键点如何操作每个应用组件.
下面是关键点要考虑的一些问题:
- 容器如何连接依赖资源?
应用如何连接数据库,如:nginx如何连接它的后端服务?
- 容器如何配置?
应用是否有配置文件?配置文件使用是基于启动参数还是环境变量?
- 容器启动前,应用是否有必须做的事情?
包括配置中的依赖资源注入,或者依赖服务
- 容器启动时,如何启动应用
通常时通过docker run或Dockerfile的cmd命令
- 容器如何服务发现?
应用通过自注册到consul等服务目录,便于其他容器发现自己.
- 如何知道容器的应用是否正常运行?
执行应用的检查状况查询,获知应用是否运行正常.实际执行可能是ping或者curl --fail等简单但是有效的指令.
- 容器负载有哪些关键指标?
性能指标,连接状态,服务容量等
- 依赖资源变化,如何更新应用使他获取新资源?
资源变化时如何操作?简单的重写配置文件?是否需要通知应用?
- 容器如何创建需要被共享的持久化数据?
数据库或应用都存在持久化数据的特殊处理方式.
- 是否有必须的操作在容器关闭前进行?
如注册中心删除前,要先移除它服务列表.
containerpilot:用于服务注册和容器生命周期管理.它在容器内通过一个简单的配置文件来触发容器事件,这种方式是我们可以实现操作自动化.触发事件包括:preStart,health,onChange,preStop,postStop.containerpilot对于自动驾驶模式来说不是必须的,但是它的重用使模式更容易实现.
consul:用于服务发现,协调应用全局状态.
和配置管理工具自动化方式有什么不同
通过配置管理工具也可以实现自动化,它是通过绑定容器配置和管理工具来创建依赖实现配置管理的自动化.这样造成对于基础服务有要求,同时不利于应用容器重用在不同的基础服务上或者不同的环境中.自动驾驶模式正是适用于降低基础设施依赖,使应用容器重用更便捷,部署更容易.
同样本地环境和生产的配置管理工具策略不同,造成本机运行问题.自动驾驶模式可以很好的解决环境问题,在不同的环境中保持相同的操作行为.
实现更简洁.自动驾驶模式只要关心在用的,并添加对应的操作逻辑即可.
流程更直观.配置管理方式单独配置应用环境,使开发者很难去了解应用的生产配置,运维也很难掌握应用变化需要修改环境配置的时点.而自动驾驶模式把操作代码和应用模板放在应用自己的代码库中,开发和运维都可以了解具体的变化流程.
和后台调度容器实现自动化的区别
一些应用自动化通过集成调度器.它通过将自动化逻辑分离为单独服务来实现.这违反了自动驾驶模式的:保持每个应用组件自动化在同一个仓库原则.
由于开发者不会经常在本地运行复杂调度器,这造成开发环境中应用生命周期自动化操作被分离并加剧环境差异问题.
依赖的基础设施
自动驾驶模式应用的基础设施需要基于容器,提供便捷和直连的网络:
面向容器
有结合基础设施规定参数和应用执行参数的api
具备使用api跨节点部署容器的能力
支持一些服务发现内嵌的格式
支持网络虚拟化,使容器具备自己的网络环境,消除端口冲突,简化容器间通讯
参考资料:
文档原文: http://autopilotpattern.io/
自动驾驶模式示例: https://github.com/autopilotpattern/workshop.git
自动驾驶模式实例说明: http://autopilotpattern.io/example