微服务专栏地址
目录
1. 简介
本文的核心是理解概念与流程，没有涉及多少具体是实际操作层面的内容，后续有计划会整理相关内容，持续交付流水线也是一块很大的内容，需要实际探索、实践、总结出最适合的方案。文章的内容大多数整理于《微服务架构于实践-王磊》，一本结合实际操作为主的介绍微服务架构实践。从一下几个方面对微服务与持续交付进行理解：
1. 简介
2. 什么是持续交付
3. 什么是持续交付的核心
4. 微服务与持续交付有什么关系
5. 如何构建一套微服务持续交付流水线
5.1 涉及哪些环节
5.2 每个环节具体包含哪些
5.2.1 开发
5.2.2 测试
5.2.3 持续集成
5.2.4 构建
5.2.5 部署
5.2.6 运维
2. 什么是持续交付
从技术上讲，持续交付是软件系统的构建、部署、测试、审核、发布过程的一种自动化实现，而其中的核心则是部署流水线。因为部署流水线能够将这几个环节有效地连接起来。
3. 什么是持续交付的核心
持续交付的核心在于三个字：小、频、快。
在持续交付过程中，需求以小批量形式在团队的各个角色间顺畅流动，并以较短的周期完成小粒度的频繁发布。实际上，频繁的交付不仅能持续为用户提供价值，而且能产生快速的反馈，帮助业务人员制定更好的发布策略。
- 小批量价值流动 ：通过建立自动化的构建及部署机制，将业务功能以小批量的方式，从需求产生端移动到用户端。
- 频繁可发布：通过建立自动化的构建及部署机制，将小批量的业务功能频繁地从需求产生端移动到用户端，持续地交付价值。
- 快速反馈：通过建立高效的反馈机制，快速验证需求是否有效。同时根据反馈，及时指导业务团队并调整策略，优先为用户交付高价值的功能。
4. 微服务与持续交付有什么关系
在微服务架构中，由于每个服务都是一个独立的、可部署的业务单元，因此，每个服务也应该对应着一套独立的持续交付流水线，可谓是“麻雀虽小，五脏俱全”。
从交付的角度来分析，对于任何一个可部署的独立单元，它都应该有一套独立的部署流水线，来有效支撑其开发、测试、构建、部署与运维的整个过程。
5. 如何构建一套微服务持续交付流水线
5.1 涉及哪些环节
- 开发
- 测试
- 持续集成
- 构建
- 部署
- 运维
5.2 每个环节具体包含哪些
5.2.1 开发
- 独立代码库：
- 对于每一个服务而言，其代码库和其他服务的代码库在物理上应该是隔离的。所谓物理隔离，是指代码库本身互不干扰，不同的服务有不同的代码库访问地址。
- 对某服务的代码进行修改，完全不用担心影响其他服务代码库中的代码，在很大程度上避免了修改一处，导致多处发生缺陷的情况。
- 服务说明文件 ：
- 服务介绍：服务提供什么功能、谁是服务的消费者
- 服务维护者：挑选1~2个团队的成员，作为服务的负责人，登记其姓名、电子邮件、电话等联系方式，以便其他团队遇到问题能及时找到服务的负责人
- 服务可用期限：服务可用周期、可用率、响应时间
- 定义环境（描述服务运行的具体环境） :生产环境、类生产环境、测试环境
- 描述开发相关的信息：如何搭建开发环境、如何运行服务、如何定位问题
- 描述测试相关的信息：测试策略、如何运行测试、如何查看测试的统计结果，譬如测试覆盖率、运行时间、性能等。
- 描述持续集成以及构建相关的信息：持续集成访问的URL、持续集成的流程描述、构建后的部署包
- 描述部署相关的信息：如何部署到不同环境、部署后的功能验证
- 描述运维相关的信息：日志聚合的访问、告警信息的访问、监控信息的访问、代码所有权归团队、有效的代码版本管理工具、代码静态检查工具、易于本地运行
5.2.2 测试
- 集成测试的二义性：对于任何一个服务而言，单元测试必不可少。但是否需要集成测试，团队可以根据喜好自行决定。
- Mock与Stub：对于单元测试而言，我们可以使用Mock框架帮助我们完成对依赖的模拟（Mock）或者打桩（Stub），譬如Java的Mockito、Ruby的RSpec等。
- 接口测试：除了单元测试覆盖代码逻辑外，至少还应该有接口测试来覆盖服务的接口部分。注意，对于服务的接口测试而言，更关注的是接口部分。譬如，作为数据的生产者，接口测试需要确保其提供的数据能够符合消费者的要求。作为数据的消费者，接口测试需要确保，从生产者获取数据后，能够有效地被处理。另外，对于服务与服务之间的交互过程，最好能设计成无状态的。
- 测试的有效性：如果单元测试的覆盖率够高，接口测试能有效覆盖服务的接口，那么基本上测试机制就保障了服务所负责的业务逻辑以及和外部交互的正确性。
5.2.3 持续集成
持续集成经过多年的发展，已成为系统构建过程中众所周知的最佳实践之一。对于每个独立的、可部署的服务而言，应为其建立一套持续集成的环境（Continuous Integration Project）。
- 当团队成员向服务的代码库提交代码后，配置好的持续集成工程会通过定期刷新或者WebHook的方式检测到代码变化，触发并执行之前开发阶段定义的静态检查、代码度量、测试以及完成构建的步骤。
- 常用的企业级持续集成服务器有Jenkins、Bamboo以及GO等，在线的持续集成平台有Travis-CI、Snap-CI等。
5.2.4 构建
每个服务都是一个可独立部署的业务单元，经过静态检查、代码度量、单元测试、接口测试等阶段后，构建符合需求的部署包。
- 部署包存在的形式是多种多样的，可以是deb包、rpm包，能在不同UNIX操作系统平台直接安装；也可以是zip包、war包等，只需将其复制到指定的目录下，执行某些命令，就可以工作。当然，也有可能是基于某特定的IAAS平台，譬如亚马逊的AMI，我们称之为映像包（Image）。
- 另外，作为容器化虚拟技术的代表，Docker（一个开源的Linux容器）的出现，允许开发者将应用以及依赖包打包到一个可移植的Docker容器中，然后发布到任何装有Docker的Linux机器上。
- 通过使用Docker，我们可以方便地构建基于Docker的部署镜像包。
5.2.5 部署
对于每个独立的服务而言，如果希望构建独立的持续交付流水线，需要选择部署环境并制定合适的部署方式来完成部署。通常，我们可以从如下两个维度考虑如何进行部署。
- 部署环境
- 基于云平台
- 基于IAAS层
- 基于PAAS层
- 基于数据中心
- 基于容器技术
- 部署方式
- 手动部署
- 脚本部署
- 基础设施部署自动化
- 应用部署自动化
- 映像部署
- 容器部署
5.2.6 运维
由于每个服务都是一个可以独立运行的业务单元，同时每个服务都运行在不同的独立节点上。因此，需要为服务建立独立的监控、告警、快速分析和定位问题的机制，我们将它们统一归纳为服务的运维。
- 监控
- 系统监控：系统监控关注服务运行所在节点的健康状况，譬如CPU、内存、磁盘、网络等
- 应用监控：关注应用本身及其相关依赖的健康状况，譬如服务本身是否可用、其依赖的服务是否能正常访问等
- 告警：当系统出现异常时，通过监控能发现异常。这时候，通过合适的告警机制，则能及时、有效地通知相关责任人，做到早发现问题，早分析问题，早修复问题。由于每个服务都是独立的个体，因此针对不同的服务，都应该能提供有效的告警机制，确保当该服务出现异常时，能够准确有效地通知到相关责任人，并及时解决问题。告警工具：PagerDuty
- 日志聚合：由于微服务架构本质上是基于分布式系统之上的软件应用架构方式，随着服务的增多、节点的增多，登录节点查看日志、分析日志的工作将会耗费更高的成本。通过日志聚合的方式，能有效将不同节点的日志聚合到集中的地方，便于分析和可视化
6. 补充
限于没有实际经验，只能通过资料和报的相关课程来了解学习持续交付，学以致用，学以致用，学以致用！！！
本文绝大部分摘录与《微服务架构与实践-王磊》！！！