精品课程网站开发,有做网站代理运营的吗,欧洲十大服务器的推荐,织梦网站内容管理系统1. 配置服务
1.1. 配置服务本身就是分布式数据库
1.1.1. 像ZooKeeper和etcd这样的配置服务
1.1.2. 受CAP定理和亚光速通信的限制
1.1.3. 可实现容量扩展#xff0c;但不具备资源可伸缩性
1.1.4. 也会遭受相同的网络创伤
1.2. 信息并不仅仅从服务流向客户端实例#xff… 1. 配置服务
1.1. 配置服务本身就是分布式数据库
1.1.1. 像ZooKeeper和etcd这样的配置服务
1.1.2. 受CAP定理和亚光速通信的限制
1.1.3. 可实现容量扩展但不具备资源可伸缩性
1.1.4. 也会遭受相同的网络创伤
1.2. 信息并不仅仅从服务流向客户端实例实例也可以向服务报告其版本号或提交SHA算法和节点标识符
1.3. 每次写入配置服务都必须经历某种共识机制才能生效
1.4. 确保实例可以在没有配置服务的情况下启动
1.5. 确保实例在配置服务无法访问时不会停止工作
1.6. 确保配置服务的某个被网络分隔的节点不具备关闭整个系统的能力
1.7. 要跨地理区域进行复制
2. 环境整备和部署服务
2.1. 部署是运维工作中的必经环节是连接开发和生产的桥梁
2.2. 部署工具本身应该配备一个部署包库
2.3. 对一些组织来说部署就是DevOps
2.4. 推式部署工具
2.4.1. 使用SSH或其他代理工具因此中央服务器可以连接到目标机器上来运行脚本
2.4.2. 这些目标机器事先并不知道自己的角色服务器会统一将角色分配给它们
2.4.3. 对于长寿命的虚拟机甚至物理主机推式部署工具就可以更简单地进行设置和管理
2.5. 拉式部署工具
2.5.1. 特别适用于资源可扩展的场景
2.5.2. 拉式部署工具更依赖各台机器了解自己的角色
2.5.3. 机器上的软件可以访问配置服务获取有关其角色的最新信息
2.6. 用于生产环境的构建包需要使用已知来源的程序库在一台“干干净净”的服务器上运行
2.7. 可重复的构建工作非常重要要确保在机器上可以运行的代码在生产环境中也能运行
2.8. 任何广泛使用的服务器软件都可用作攻击武器包括构建服务器诸如Jenkins、Bamboo或GoCD
2.8.1. 构建系统本身的插件是直接从网上下载的
2.9. 金丝雀部署是构建工具需要完成的一项重要工作
2.9.1. “金丝雀”指一小组实例它们率先获得了系统的新版本
2.9.2. 在一段时间内运行新版本的实例会与运行旧版本的实例共存
2.9.3. 如果金丝雀实例行为异常或者其度量指标一直很低那么该构建就不会推送给剩余的实例安装
2.10. 金丝雀部署的目的就是在构建包到达用户之前拒绝其中糟糕的构建包
3. 命令与控制
3.1. 只有当实例需要花费很长时间才能做好运行前的准备工作时实时控制才有必要
3.2. 控制点
3.2.1. 重置断路器
3.2.2. 调整连接池大小和超时
3.2.3. 禁用特定的出站集成
3.2.4. 重新加载配置
3.2.5. 开始或停止接收负载
3.2.6. 特性开关
3.3. 开发人员不相信运维人员能正确地部署软件并运行脚本
3.4. 运维人员不允许开发人员登录到生产机器更新数据库模式
3.5. 这个信任的破裂本身就是一个需要解决的问题
3.5.1. 绝对不要在生产代码中构建一个自我毁灭“按钮”
3.5.2. 许多服务会采取公开一些控制的方法来更新数据库模式或者删除并重新设置所有数据
3.6. 刷新缓存按钮这也是非常危险的
3.7. 命令队列
3.7.1. 一个共享的消息队列或发布-订阅总线所有的实例都可以监听
3.7.2. 有了命令队列一窝蜂效应就更容易发生了
3.7.3. 为每个实例添加一个随机的延迟时间让它们能够分散地执行命令这是避免一窝蜂效应的好方法
3.8. Watir或RoboForm这样的图形用户界面测试工具
3.9. 对生产环境中长期的运维工作来说图形用户界面是糟糕的管理界面。长期运维的最佳界面是命令行
3.10. 所有构建的软件要么必须维护要么被迫抛弃
3.11. 要选择那些适合团队规模和工作负载规模的工具
3.12. 可以从系统可见性开始使用日志记录、跟踪和度量指标来创建明晰性
3.13. 当面对更大或更动态的系统时可以使用配置、整备和部署服务来获得杠杆作用
3.14. 一旦系统在某种程度上稳定下来并且问题显露出来就要建立控制机制这样就能进行更精确的控制而不仅仅是重新配置和重新启动实例
3.15. 相比那些高度动态的环境部署到长寿命机器上的大型系统从控制机制中受益更多
4. 平台厂商
4.1. 相对于云供应商平台能够提供一个与之不同的特性——位置无关性
4.2. Kubernetes、Apache Mesos、Cloud Foundry以及Docker的Swarm Mode
4.3. 既然已经在平台上花了大价钱就应该充分加以利用
4.3.1. 不要尝试在它外面再包装一层API或自己提供一套脚本
5. 工具清单
5.1. 日志收集和搜索
5.2. 度量指标收集和可视化
5.3. 部署
5.4. 配置服务
5.5. 实例安置位置
5.6. 实例和系统可视化
5.7. 调度
5.8. IP地址、覆盖网络、防火墙和路由管理
5.9. 自动扩展控制器
5.10. ⑩告警和通知
6. 要点
6.1. 每个解决方案都会带来新问题。随着系统容量的水平扩展和垂直扩展我们几乎将一切虚拟化了
6.2. 一旦知道整个系统发生了什么就能采取干预措施
6.3. 需要了解自动化让所有事情都运行得更快带来的问题
6.3.1. 自动化缺乏人的判断力所以当出错时错误会发展得很快这就需要我们在自动化中建立安全机制
