《微服务设计》6、7章

上一篇 《微服务设计》4、5章笔记

第六章 部署

6.1 持续集成

提交与现有的不断集成，所有人不断地同步。

思考

• 你真的在做CI么？
• 是否每天签入代码到主线
• 是否一组测试来验证修改
• 当构建失败之后，团队是否会优先处理

6.2 把持续集成映射到微服务中

- 如果你修改了一个服务，那到底会影响了多少个服务呢？ - 如果估量，所有系统都要校验这个服务呢？ - 将一个代码库的子目录映射到不同的构建中 - 跨服务怎么办呢？ ==》测试用例要跟着服务走

CD 持续交付（不断验收，与线上要求相匹配）

==》保证微服务可以独立部署

6.4 平台特定的构建物

• 需要Apache或Nginx
• 不同技术栈问题（Ansible）

6.5 使用系统支持的构建物

centos RPM，Ubuntu deb.（在可控制的机器上）
缺点：编写脚本过程
定制化镜像（虚拟机之类的）

不可变的服务器

1. 源码配置与服务器不一致？
2. 走流程验证
3. 服务器备份

环境

1. 主机隔离不一致
2. 配置不一样
3. 各种差异
4. ==》反馈问题不一样

服务器配置

1. 要知道部署的环境？
2. 不能讲数据库密码提交到源码？
3. 》单独管理配置？

服务与主机映射

1. 监控单个服务还是监控主机呢？
2. 一个服务出问题了，也可能影响到其他服务？
   
   
   如何治理？

对某些容器表示质疑？

一个主机多个服务

• 在jvm上做程序生命周期管理比较难。
• 只包含http服务器

一个主机一个服务（虚拟化问题）

• 寻找复杂根源
• 如果没有PaaS平台，就会大大减少复杂性
• 平台即是服务（Heroku）

6.10 自动化

REA 上线速度提升

6.11 从物理机到虚拟机

• 多台主机的成本高
• 隔离了，总体可用的资源也少了。

工具

1. hypervisor
2. vagrant

liunx 容器(共享内核)

• 例如：lxc
• 好处
  • 加快了放映时间
  • 启动快
• 特例：
  • 有些进程可能会跳出容器
  • 或与其他容器。

docker（与centos很好兼容）

1. 轻量级
2. 抽象，简单
3. 比作：单机的PaaS，你还需要一些集群管理的工具（Kubenetes和CoreOS）
4. 比较PaaS好多了，也做对了不少东西。

小结：

• 自动化管理是非常重要的
• 构建部署（人员配合，规范）

推荐书籍：《持续交付》

测试

如何高效和有效测试分布式系统呢？

7.1 测试类型

近年来，理解你自己的系统。放弃大规模的手工测试，尽可能地使用自动化。

7.2 测试范围

测试金字塔

缺点：反馈时间长

1. 单元测试（通常只是一个函数）==》驱动测试
2. 服务测试（单独服务测试）
3. 端对端测试

mock和打桩

• 打桩:被测试服务的请求创建一些有着预响应的打桩服务。
• mock:进一步校验请求本事是否被正确请求。（过度mock会使测试变得脆弱）

微妙的端到端测试

• 使用什么版本？
• 测试哪些服务
• 测试服务有重叠？
  • 引入一个独立端对端的阶段测试。
  • 端对端有一些缺点

脆弱的测试

• 服务的失败，可能来源于另外一个服务。
• 不确定性
• 服务拥有者写测试用例

Pact 消费者驱动的测试工具

• 沟通
• 消费者和生产者要有良好的信任和沟通。

7.9 还应该使用端到端测试吗？

• CDC工具+监控
• 不断减少端对端依赖

再怎么测试无法消除所有的缺陷

所以要做监控和修复！！

部署

• 金丝雀发布，将部分流量引流到新的部署系统。（验证）
• 平均修复时间+平均故障间隔

7.11 跨功能测试

• 性能测试
• 延迟性，用户量
• 最初没有足够系统资源（但有不能拖延上线）
• 性能测试，不可能在每次构建时候执行（一周或一个月吧）
• 运行了越是久远，发生问题。 （很难）

推荐书籍：

• 《敏捷软件测试》
• 《Scrum 敏捷软件开发》
• 《测试驱动的面相对象软件开发》