微服务设计-读书笔记6
部署
一、把持续集成映射到微服务
1、 把所有的微服务放在一个代码库中，并且只有一个CI构建。
这种方法的缺点是任何的改动，所有的服务都要进行验证和构建，浪费时间；如果一次提交导致构建失败，那么在构建修复之前，与其他服务相关的代码就无法提交。
2、将一个代码库的子目录映射到不同的构建中
这种方法，保留了一个代码库，但是存在多个CI会分别映射到代码库的不同部分，虽然较上一种方法更好，并且简化检出/检入的流程，但是对提交的限制很少，容易导致同时提交多个服务的修改，从而做出将多个服务耦合在一起的修改。
3、每个微服务一个源代码库和一个CI构建
这种方式中，每个微服务都有一个代码库,并与相应的CI绑定。当对代码库进行修改时，可以只运行相关的构建以及其中的测试。各个服务之间的持续集成不会相互耦合。
二、构建流水线和持续交付
构建流水线
构建流水线能很好地跟踪软件的进度，构建物会在第一个环节生成，然后会被用在整个流水线中，每完成一个阶段，就离终点更近一点。
持续交付（Continuous Delivery, CD）,在持续集成和构建流水线的概念上发展而来，强调每次提交是否达到了部署到生产环境的要求。
三、构建物
1、 有一类构建物是平台特定的，比如Java的JAR、Python的egg。不同平台构建物的混合部署会很复杂（当然也存在一些工具支持通用技术栈的构建物部署，比如Chef、Puppet、Ansible）
2、操作系统构建物，可以避免不同技术栈下的构建物所带来的问题，比如RedHat、CentOs系统的RPM、Ubuntu的deb包、Windows的MSI。使用操作系统特定的构建物的优点是可以很好地屏蔽底层技术，只需要简单使用内置的工具完成软件安装即可；缺点是刚开始编写构建脚本的过程比较困难，而且如果需要部署到多种系统的话，维护不同版本的构建物开销也很大。
3、定制化镜像，为了部署服务，可能需要先安装Orace JVM、数据库软件，还有其他的，比如使用colleted来收集操作系统的状态，使用logstash来做日志聚合、nagios来做监控，每次部署新环境都要花费大量的时间，一种解决方法就是创建一个虚拟机镜像，其中包含了常用的软件依赖，然后在部署软件时，只需要根据该镜像创建一个实例，之后再其上安装最新的服务版本即可。
这种方法的优点是，只需要构建一次镜像，不需要再花时间安装相应的依赖。缺点是，构建镜像会花费时间，创建的镜像文件也很大。
注：Packer可用来简化镜像创建过程（它可以从同一套配置中生成不同平台的镜像）
更进一步，可以把服务本身也包含在镜像中，这样就把镜像变成了构建物。只要启动镜像，服务就已经就绪了；
另一种基于镜像的扩展是不可变服务器，为了避免配置漂移（版本中的配置与部署的环境的配置不同），可以禁止对任何运行的服务器做手动的修改。任何的改动都要经过构建流水线来创建。
四、环境
当构建物在CD流水线的不同阶段移动时，配置环境是不同的。环境之间的不同可能引起一些问题。我们期望CD流水线各个阶段的环境都接近生产环境，但是有时重建类生产环境的时间代价很高，所以需要做出类生产环境和快速反馈之间的平衡。
（1）、服务配置
只创建一份构建物，并将配置单独管理，为不同的环境准备不同的配置信息，通过运行参数或开关来启动相应的配置。
五、服务与主机的映射
每台主机应该部署多少服务？服务在主机的部署模型有哪些？
（1）、单主机多服务
这种模型优点是简化开发人员工作，缺点是每个服务的监控变得困难（很难知道主机的资源是如何被各个服务分配的）、服务的部署变得困难（很难保证服务之间不会相互影响，服务的依赖是否会冲突）、对团队的自治性不利、增加了对单个服务扩展的复杂性（有时候不能对服务一视同仁）。
（2）、应用容器部署
这种模型是单主机多服务的一种特例。应用程序容器是指.NET应用的IIS、Java的servlet容器等。
这种模型的优点，节省语言运行时开销（嵌入式容器除外），缺点是限制技术栈的选择（一种容器仅支持一种技术栈）、限制自动化和系统管理技术的选择、单主机多服务的缺点依然存在。
（3）、单主机单服务
这种模式的优点是简化了监控和错误恢复，减少了潜在的单点故障，服务部署更加灵活。缺点是，资源利用率不高（虚拟化除外）、主机数量增多带来的管理复杂性。
（4）、平台即服务
PaaS(Platform-as-a-Service, 平台即服务)，这些平台能帮我们自动配置机器然后运行，其中一些平台还能够透明地对系统进行伸缩管理。
PaaS平台能够很好地管理数量众多的组件。但特定用户的特定需求通常不能满足。
六、自动化
自动化能够帮助开发人员保持工作效率，使用自动化，主机控制、服务部署等工作量就不会随着主机数量的增加而增长，服务监控、日志收集也更容易操作。
七、虚拟化
管理大量主机的关键之一是找到一些方法把现有的物理机划分成小块，类似于VMWare这样的传统虚拟化技术或者AWS，可以大大减少管理主机的开销。
（1）、传统的虚拟化技术
传统的虚拟化技术，包含标准的虚拟化和基于容器的虚拟化，每个虚拟机可以有不同的操作系统，并且有其各自的内核，可以认为是完全密封的机器。
虚拟化技术就类似抽屉隔板的作用，隔板本身也是要占用资源的，虚拟化的主机越多，虚拟化本身占用的资源就越多。
（2）、Vagrant
Vagrant是一个很有用的部署平台，通常在开发和测试环境使用，而非生产环境，它可以在本地机上创建一个虚拟的云（底层使用标准的虚拟化系统），可以轻松创建类生产环境，使用它能够带来快速反馈的好处，缺点是开发机上会有很多额外的资源消耗。
（3）、Linux容器
Linux容器可以创建一个隔离的进程空间，可以在这个空间里运行其他进程，常见的有Solaris Zones、OpenVZ、LXC,最流行的是LXC（现在基本所有的现代Linux内核都提供了LXC）。LXC主机，每个容器可以运行不同的操作系统，但必须共享相同的内核。
LXC优点是，容器更加轻量，比完整的虚拟机占用的资源少，启动更快，容器对资源的利用率更高。缺点是端口映射等于外部的联系需要自己做、容器的隔离不彻底，可能会与底层主机发生干扰。
（4）、Docker
Docker是构建在轻量级容器之上的平台，可以在Docker中创建和部署应用，Docker的管理可以参看开源工具Kubernates和CoreOS集群技术。Docker加上合适调度层的解决方案在很多地方被称为CaaS(Container-as-Service, 容器即服务)。
八、统一部署接口
不管底层平台和构建物是什么，使用统一接口来部署服务很有用。参数化的命令行调用时触发任何部署的最合理方式。Fabric是一个被设计用来将命令行调用映射到函数的Python库，同时也能够提供类似SSH这样的机制来控制远程机器。