《微服务设计》6、7章
上一篇 《微服务设计》4、5章笔记
第六章 部署
6.1 持续集成
提交与现有的不断集成，所有人不断地同步。
思考
- 你真的在做CI么？
- 是否每天签入代码到主线
- 是否一组测试来验证修改
- 当构建失败之后，团队是否会优先处理
6.2 把持续集成映射到微服务中
- 如果你修改了一个服务，那到底会影响了多少个服务呢？ - 如果估量，所有系统都要校验这个服务呢？ - 将一个代码库的子目录映射到不同的构建中 - 跨服务怎么办呢？ ==》测试用例要跟着服务走
CD 持续交付（不断验收，与线上要求相匹配）
==》保证微服务可以独立部署
6.4 平台特定的构建物
- 需要Apache或Nginx
- 不同技术栈问题（Ansible）
6.5 使用系统支持的构建物
centos RPM，Ubuntu deb.（在可控制的机器上）
缺点：编写脚本过程
定制化镜像（虚拟机之类的）
不可变的服务器
- 源码配置与服务器不一致？
- 走流程验证
- 服务器备份
环境
- 主机隔离不一致
- 配置不一样
- 各种差异
- ==》反馈问题不一样
服务器配置
- 要知道部署的环境？
- 不能讲数据库密码提交到源码？
- 》单独管理配置？
服务与主机映射
- 监控单个服务还是监控主机呢？
- 一个服务出问题了，也可能影响到其他服务？
如何治理？
对某些容器表示质疑？
一个主机多个服务
- 在jvm上做程序生命周期管理比较难。
- 只包含http服务器
一个主机一个服务（虚拟化问题）
- 寻找复杂根源
- 如果没有PaaS平台，就会大大减少复杂性
- 平台即是服务（Heroku）
6.10 自动化
REA 上线速度提升
6.11 从物理机到虚拟机
- 多台主机的成本高
- 隔离了，总体可用的资源也少了。
工具
- hypervisor
- vagrant
liunx 容器(共享内核)
- 例如：lxc
- 好处
- 加快了放映时间
- 启动快
- 特例：
- 有些进程可能会跳出容器
- 或与其他容器。
docker（与centos很好兼容）
- 轻量级
- 抽象，简单
- 比作：单机的PaaS，你还需要一些集群管理的工具（Kubenetes和CoreOS）
- 比较PaaS好多了，也做对了不少东西。
小结：
- 自动化管理是非常重要的
- 构建部署（人员配合，规范）
推荐书籍：《持续交付》
测试
如何高效和有效测试分布式系统呢？
7.1 测试类型
近年来，理解你自己的系统。放弃大规模的手工测试，尽可能地使用自动化。
7.2 测试范围
测试金字塔
.png)
缺点：反馈时间长
- 单元测试（通常只是一个函数）==》驱动测试
- 服务测试（单独服务测试）
- 端对端测试
mock和打桩
- 打桩:被测试服务的请求创建一些有着预响应的打桩服务。
- mock:进一步校验请求本事是否被正确请求。（过度mock会使测试变得脆弱）
微妙的端到端测试
- 使用什么版本？
- 测试哪些服务
- 测试服务有重叠？
- 引入一个独立端对端的阶段测试。
- 端对端有一些缺点
脆弱的测试
- 服务的失败，可能来源于另外一个服务。
- 不确定性
- 服务拥有者写测试用例
Pact 消费者驱动的测试工具
- 沟通
- 消费者和生产者要有良好的信任和沟通。
7.9 还应该使用端到端测试吗？
- CDC工具+监控
- 不断减少端对端依赖
再怎么测试无法消除所有的缺陷
所以要做监控和修复！！
部署
- 金丝雀发布，将部分流量引流到新的部署系统。（验证）
- 平均修复时间+平均故障间隔
7.11 跨功能测试
- 性能测试
- 延迟性，用户量
- 最初没有足够系统资源（但有不能拖延上线）
- 性能测试，不可能在每次构建时候执行（一周或一个月吧）
- 运行了越是久远，发生问题。 （很难）
推荐书籍：
- 《敏捷软件测试》
- 《Scrum 敏捷软件开发》
- 《测试驱动的面相对象软件开发》
