6.1 持续集成简介
CI(Continuous Integration,持续集成)
CI流程中我们经常会生成一些构建物（artifact）以供后续验证使用，理想情况下，这些构建物应该只生成一次，然后在本次提交所对应的所有部署环境中使用。这不仅可以避免重复做一件事，还可以保证部署上线的构建物与测试通过的那个是同一个。（这个我们ys做的很不好，不知道是意识问题，还是其他原因）
CI的好处很多，通过它，我们能够得到关于代码质量的某种程度的快速反馈。
CI的好处：积累的修改越少，越容易部署或者回滚，越容易测试，越不容易造成破坏性修改，小步快跑。
你真的在做CI吗？
- 你是否每天签入代码到主线（渐变与突变）
- 你是否有一组测试来验证修改（没有自动化测试的敏捷是扯淡）
- 当构建失败后，团队是否把修复当作第一优先级的事情来做。（目前开发者中心有类似的功能，只不过做的还不是很好用，做的启动检测而不是构建检测）
6.2 把持续集成映射到微服务
项目初期(all in one)：
所有微服务在一个CI中，一个CI产生多个构建物
中级阶段（一个代码仓，多个CI映射到代码库的不同部分）
高级阶段（完全分离，互不干涉）
6.3 构建流水线和持续交付
构建流水线可以很好地跟踪构建进度：每完成一个阶段，就离终点更近一步。流水线也能够可视化本次构建物的软件质量。构建物会在整个构建的第一个环节生成，然后它会被用在整个流水线中 。
CD(Continuous Delivery,持续交付)，CD能够检查每次提交是否达到了部署到生产环境的要求，并持续地把这些信息反馈给我们，它会把每次提交当成候选发布版本来对待。
在微服务的世界，我们想要保证服务之间可以独立于彼此进行部署，所以每个服务都有自己独立的CI。在流水线中，构建物会沿着上线方向进行移动。构建物的大小和形态可能会有很大差别。
不可避免的例外：
当一个团队开始启动一个新项目时，尤其是什么都没有的情况下，你可能会花很多事件来识别出服务的边界。所以，在你识别出稳定的领域之前，可把初始服务都放在一起，包括流水线。
感想：渐进的思想。没有人不想一次性把东西做好，关键在于问题的复杂度，如果问题的复杂度足够高，那渐进式迭代就是非常必要的，没必要难为别人，也没必要难为自己。（平台功能，公共功能）
6.4 平台特定的构建物
这个我们不需要关心，因为我们基本不用Ruby,Python这些。。。
6.5 操作系统构建物
这个也基本不用关心，前端后端的构建产物都是跨平台的，而且我们现在部署的环境基本都是Linux.
6.6 定制化镜像
开发者中心都基于docker构建，基本不用关心了，如果想在本地用docker（Linux），也可以，拉取开发者中心对应的镜像，自己写dockerfile就ok.
6.6.1 将镜像作为构建物
6.6.2 不可变服务器（不知道生产环境如何，现在各个环境，都没有这功能）
通过把配置都存在版本控制中，我们可以自动化重建服务，甚至重建整个环境。但是，如果部署完成后，有人登录到机器上修改了一些配置，这就导致机器上的实际配置和源代码管理中的配置不在一致，这个问题叫做“配置漂移”
禁止对任何运行的服务器做手动修改。无论修改多么小，都需要经过构建流水线来创建新的机器。严格的话，甚至可以禁用相关机器的SSH，以确保没有人能够登录到机器上做任何修改。
自动带来的不仅仅是方便，还有稳定，试想一个场景，如果能代码构建自动化，硬件资源根据配置文件自动初始化运行环境（cpu和核数，内存大小，各种中间件安装），自动化配置文件拉取，自动化全新数据库初始化。。。这样的场景下得多爽。
6.7 环境
在CD流水线的不同阶段之间移动时，它也会被部署到不同的环境中。
一个用来运行耗时测试，一个用来做UAT,一个用来做性能测试，另一个用于生产环境。。。。
比如，我可以在166服务器上做代码规范检测，做单元测试，发送提醒邮件等工作，然后在开发者中心部署的时候可以选择关闭这些功能。
不同环境的差异可能会导致部署系统的表现不同，产生相关bug，这就需要我们分辨不同环境的差别，而在测试环境下又要尽可能模拟到线上环境的场景。
6.8 服务配置
最小化环境间配置的差异，如果不同环境之间的配置差异很大，那么你可能就只能在特定的一套环境中发现某个特定的问题，这是极其痛苦的。（我这儿是正常的啊，重启下系统试试？退出下系统重登录下试试？你操作姿势不对。。。）
一个好的办法是只创建一个构建物，将配置单独管理，或者使用专用的系统来提供配置（配置中心）。
6.9 服务与主机之间的映射
每台机器应该有多少个服务？
6.9.1 单主机多服务
好处：
- 从主机管理的角度来看，它更简单。更容易管理
-
从成本角度来看，虚拟化的基础设施本身也会占用一部分资源，不同的虚拟化技术占用大小不同而已。单主机多服务，这样资源都花在应用上。
image.png
坏处：
- 监控变得更加困难，监控CPU使用率的时候，应该监控每个单独的服务还是整个机器？服务之间的互相影响也不可避免。
- 不同的服务对组件以及环境的依赖不同，多个服务在一台主机上，很难保证对一个服务的部署不会影响其他服务。
- 对团队自治性也不利，这台服务器就是不同服务团队之间的耦合点。
- 增加对单个服务进行扩展的复杂性。每个服务的需求是不同的，但因为在一起，我们不得不对它们一视同仁。
之前单主机多服务很多时候是由于虚拟化技术不成熟，想要加机器，要么买，要么租，反正得申请，往往需要很长的时间，而现在虚拟化技术的发展让内部基础设施的搭建更加灵活和方便，单主机多服务很多时候没有必要，尤其是在线上环境。
6.9.2 应用程序容器
基于IIS的.NET应用程序部署，或者基于servlet容器的Java应用程序部署比较熟悉的化，应该比较了解把不同的服务放在同一个容器中，再把容器放置在单台主机上的模式。
6.9.3 每个主机一个服务
这样做，我们才有可能采用一些不同的部署技术。单主机单服务的模型会大大简化问题的排查，这绝对是减小微服务复杂性的一个方法。但同时，主机数量的增加也是一个问题，管理更多的主机会给运维带来比较大的挑战。所以，必须得有PaaS
微服务时代，人肉运维绝对是又累效果又差
6.9.4 平台即服务(PaaS)---开发者中心
Paas(Platform-as-a-Service,平台及服务)。平台可以帮你自动配置机器然后运行，进行伸缩管理，允许你控制运行服务的节点数量。。。
PaaS可以帮你管理数量众多的组件，帮你管理部署的环境，PaaS应该成为部署平台的首选，而不是自己管理主机以及每个服务的部署。
6.10 自动化
单体时代，管理机器，管理配置，管理构建，这些在你看来都比较简单。但到了微服务情况下，数量会让你绝望，主机的数量，配置的数量，环境的数量，构建流水线的数量，日志的收集，监控。。。
自动化可以帮助开发人员保持工作效率，大大简化开发人员的工作。理想情况下，开发人员使用的工具链因该和部署生产环境时用的完全一样，这样就能及早发现问题。
使用自动化技术非常重要。你能否通过写一行代码来启动或者关闭一个虚拟机？你能否自动化部署写好的软件？你能否不需要手工干预就完成数据库的变更？想要游刃有余的应对复杂的微服务架构，自动化是必经之路。
6.11 从物理机到虚拟机
6.11.1 传统的虚拟化技术
hypervisor本身也需要一定的资源来完成自己的工作，它会占用CPU,I/O和内存等。hypervisor管理的主机越多，占用的资源就越多。这意味着，你把物理机切分的越小，能够得到的收益也越有限。
6.11.2 Vagrant
没用过。。。
6.11.3 Linux容器
首先，不需要hypervisor;其次，尽管每个容器可以运行不能的操作系统发行版本，但必须共享相同的内核（因为进程树存在于内核中）。这意味着，我们的主机操作系统可以运行Ubuntu，而在容器中可以运行CentOS,只要它们的内核相同即可。
Linux容器可以启动的非常快。对于一台虚拟机来说，花几分钟时间来启动很正常，但是Linux容器通常只要几秒钟就能完成启动。
容器更轻量，所以在相同的硬件上能够运行的容器数量，比能够运行的虚拟机数量要大的多。
6.11.4 Docker
Docker是构建在轻量级容器上的平台。它帮你处理了大多数于容器管理相关的事情。
Docker本身并不能解决所有问题，它只是一个在单机上运行的简单PaaS。还需要一些工具，来帮助我们跨多台机器管理Docker实例上的服务。在这个领域，Google开源工具Kubernetes和CoreOS集群技术能够提供一定的帮助。
6.12 一个部署接口
不管用于部署的底层平台和构建物是什么，使用统一接口来部署给定的服务都是一个关键的实践。
作者说“在这个领域工作了这么多年后，我深信，参数化的命令行调用是触发任何部署的最合理的方式。”，从Widnows批处理到bash，再到Python Fabric脚本等。为什么脚本这么受欢迎，我个人理解这和自动化是分不开的，很多聪明的程序员是比较懒的，它们讨厌重复的劳动，类似的劳动，但他们不是抱怨，而是写了公用的或者自用的脚本来解放双手，让更多的精力投入在更有价值的地方。所以，你会发现，Linux同学，尤其是Linux下的运维同学，特别喜欢写脚本，尤其是复用脚本。
