微服务 - 很小，专注于做好一件事

0x00 微服务

微服务是一种分布式系统解决方案，各服务间协同工作，且每个服务都有自己的生命周期。

0x01 微服务的优点

技术异构：能帮助你轻松的采用不同技术。 新技术通常伴随着风险，但通过微服务可以将新技术应用到流量不大的业务上，从而降低风险。

弹性：好的微服务架构能够避免级联故障，即使一个业务不可用，也不会造成整体业务瘫痪。

扩展：可以按需对热点服务进行扩容，从而节省成本。

简化部署：可以更快速的对特定部分代码进行部署，即使出了问题也可以快速回滚。

利于组织管理：微服务避免出现较大代码库导致团队分工混乱。

可组合性：可使用不同方式构建应用。

对可替代性的优化：重构一个微服务是简单的。

0x02 架构师

0x03 什么样的服务是好服务

松耦合

• 能够独立修改及部署单个服务而不需要修改系统的其他部分。

高内聚

• 把相关的行为聚集在一起，方便在一处修改即可尽快发布。

0x04 编排与协同

使用编排：会依赖于某个中心服务指导整个过程。

• 客户服务作为中心控制点，承担太多职责，其他服务沦为CRUD服务。

使用协同：仅仅告知系统各部分各自的职责，把细节留给他们自己。

• 可以使用异步的方式触发一个事件，其他各服务订阅这个事件，并做相应处理。
• 协同方式可以有效降低系统耦合度，但需要额外的工作来对业务流程做跨服务监控。

0x05 持续集成（CI）

CI能够保证新提交的代码与已有代码进行集成，从而让所有人保持同步。CI服务器会检测到代码已经提交并签出，然后会花一些时间来验证代码是否通过编译及测试。

CI能够得到关于代码质量的快速反馈，允许我们更快速、更容易地修改代码。

0x06 定制化镜像

假设我们要扩容一个业务，部署一个Java程序，首先使用标准Ubuntu镜像构建，再安装Oracle JVM，整个过程至少花费5分钟，再做一些日志，数据收集的初始化，随着时间的推移，越来越多的东西被加入，自动化配置环境所需的时间也会越来越长。从而，一种减少启动时间的方法：创建虚拟机镜像。

虚拟机镜像中包含了一些常用的依赖，可以把公共的工具安装在镜像上，然后在进行扩容、部署的时候，直接使用镜像创建实例即可。

不可变服务器：通过禁止新实例的SSH或相关方法杜绝配置漂移，直接通过镜像作为构建物构建。

缺点：

• 构建镜像会花费大量时间
• 产生的镜像可能会很大
• 构建不同平台上镜像所需的工具链是不一样的

0x07 服务与主机

单主机多服务

直接运行多个服务

应用程序容器 例如：在一个Java servlet容器中部署五个Java服务，只需启动一个JVM即可。

缺点：

• 限制技术栈选择
• 限制自动化和管理系统的选择
• 监控能力难以支撑微服务聚合监控
• 很多容器启动时间很长

单主机单服务

可以实现部署自由，减少潜在单点故障。是微服务架构中比较好的模型。

缺点：

• 主机数量的增加，导致管理、成本代价。

0x08 从物理机到虚拟机

如果你需要把每个服务部署到单台物理机上，那么大概你会被项目经理打死。虚拟化技术允许我们把一台物理机分成多台独立主机，每台主机可以运行不同的东西。

传统虚拟化技术

虚拟化技术就像隔板，将一个大箱子分隔成不同部分。

如图左边叫做类型2虚拟化，底层的物理机和同一个hypervisor之上的其他虚拟机之间都是隔离的。

但同时hypervisor本身也需要一定资源完成自己的工作，它所管理的主机越多，占用也越多。

ps 类型1 虚拟化指的是只能运行在裸机上，而不能运行在操作系统上的技术

Linux容器

Linux容器可以创建一个隔离的进程空间，进而在这个空间中运行其他进程。

内核帮我们完成给这些容器分配资源的任务，具体形式：Solaris、OpenVZ、LXC。

内个容器可以运行不同操作系统发行版，但必须共享相同内核（进程树存在于内核中）。

Linux容器启动迅速，但隔离性稍差，比如可能与底层平台发生干扰。

Docker

Docker是构建在轻量级容器之上的平台。

你可以在Docker中创建、部署、打包应用并上传registry。

快速配置、随处可用。

总结： 自动化！

0x09 测试

单元测试

• 通常只测试一个函数和方法调用。通过TDD（测试驱动开发）写的测试就属于这一类。
• 单元测试中，不会启动服务，对外部文件或网络连接使用也很有限。
• 通常情况需要大量单元测试，设计合理的情况下，他们会运行的非常快。
• 单元测试是面向技术的，而非面向业务的。

服务测试

• 绕开用户界面、直接针对服务进行测试。
• 只测试一个单独的服务可以提高测试的隔离性，这样能更快定位解决问题。

端到端测试

• 覆盖整个系统，需要模拟用户交互。

0x10 部署

蓝/绿部署

• 部署两份服务，但只有一份接受真正请求。
• 不断测试新服务，直到稳定，再将生产负荷部署到新服务。
• 保留旧服务一段时间，方便意外情况下的快速恢复。

金丝雀发布

• 通过将部分生产流量引流到新部署的服务，来验证服务是否按预期执行。
• 也可以采用复制真实流量来测试新服务的正确性。