7.携程架构实践 --- IaaS ＆ PaaS

第7 章 IaaS ＆ PaaS 
	如果想要产品交付越来越快，就需要提升基础设施的交付能力。虚拟化技术，通过OpenStack平台统一了虚拟机/物理机的资源交付，提供了真正意义上的IaaS服务。
一套稳定的，可靠的，高效的持续交付平台---PaaS平台应用而生。在PaaS平台，我们从持续交付入手，打通了持续交付过程中核心的几个部分：资源，版本，发布。在版本
方面，引入了git，包管理工具，依赖管理工具，静态代码扫描工具，对各种语言进行了标准化治理。同时，新打造的build平台，统一了编译，打包的标准和过程；在发布
方面，配合应用治理系统的上线，打通了服务发现和元数据管理系统，使应用交付更加稳定，可靠和高效。
	
	进行DevOps实践时，治理是永恒的话题，而标准化是治理的前提。任何产品想要达到稳定，可靠，高效的状态，必须通过一定的规则，手段进行标准化。标准化可以
缩小问题范围，降低问题复杂度，提升一致性，而让一件事情具备反复执行的能力。

	容器的产生是对虚拟机的降维打击，那么k8s的出现就是对 "IaaS+PaaS"的降维打击。有 OpenStack,Mesos,K8s,Swarm。K8s的出现，就把Iaas和PaaS融为
一体，不仅关注应用的交付，还为应用治理提供了各种解决方案。Deployment,StatefulSet,DaemonSet等概念都是从应用治理的角度去思考和设计的。


7．1 网络架构演进 
		在云计算模型中，IaaS层会对物理的计算，网络和存储资源进行虚拟化和池化，以更细粒度，更易管理和扩展的方式交付给上层的工具和用户使用，后者无需
	关心物理设备的相关细节。在一个提供IaaS服务的现代数据中心中，网络通常分为以下两层：
		1.数据中心网络
		2.虚拟化网络

		数据中心网络，也称为物理网络，通过物理网络设备将所有服务器连接成一个数据中心。在物理网络之上，云计算平台(如OpenStack)会创建一层虚拟化网络，
	并将其中的虚拟资源分配给用户使用。所以云计算平台的网络架构既包括 物理网络，也包括虚拟化网络。

		在云计算时代，xc的网络架构经历了以下演进过程：
			1.基于VLAN的二层网络
			2.基于VXLAN的大二层SDN网络
			3.基于BGP的三层SDN网络

		数据中心的物理网络拓扑结构是典型的 "接入---汇聚---核心" 三层网络架构。

	7．1．1 基于 VLAN 的二层网络 
		第一代方案的缺点：
			1.在硬件拓扑上，三层网络架构的可扩展性不好，而且所有的OpenStack网关都配置在核心路由上，使得核心路由称为潜在的性能瓶颈。
			2.在这种传统的二层网络里，虚拟机只能在一个很小的范围内迁移，大大限制了容灾和故障恢复能力。

		另外，还有一些新的需求，和子公司网络打通，把子公司当做独立的租户，因此有了多租户和VPC的需求。

	7．1．2 基于VXLAN 的大二层SDN 网络 
		SDN控制平面和数据平面协议：
			在数据中心网络层，数据平面基于VXLAN协议，控制平面基于MP-BGP EVPN 协议(在设备之间同步控制信息)，这两者都是RPC标准协议。

			网关是分布式的，每一个leaf节点都是网关。VXLAN协议的封装和解封装都在leaf节点内完成，leaf节点以下是VLAN网络，leaf节点以上是VXLAN
		网络。

	7．1．3 基于BGP 的三层SDN 网络 
		第二代方案的问题：	
			1.随着集群规模的进一步扩大，中心式的IPAM逐渐成为性能瓶颈。
			2.目前的方案中，IP地址在整张大二层网络中都是可漂移的，因此故障范围特别大。
			3.较高的容器部署密度本身会在大二层网络的交换机表项(NLRI)带来压力，这涉及一些大二层涉及本身及硬件的限制。

		最终选择基于"Local+IPAM+BGP"的网络方案，其中软件基于"Cilium+Brid+CNC"。

		Cilium 是最近出现的一套容器网络解决方案。

7．2 K8s 和容器化的实践 
	7．2．1 部署架构 
	7．2．2 网络 
	7．2．3 调度 
	7．2．4 存储 
	7．2．5 监控 
	7．2．6 容器化 

7．3 混合云 
	7．3．1 混合云整体设计 
	7．3．2 混合云网络＆ 安全 
	7．3．3 混合云计费＆ 对账 
	7．3．4 混合云运维 

7．4 持续交付 
	7．4．1 发布的艺术 
		1.蓝绿部署
		2.滚动部署
		3.金丝雀发布
		4.暗部署
		5.A/BTesting
		6.重建部署

	7．4．2 Tars 系统设计 
		1.Croller 发布模式
			也称为火车发布：每天有固定的车次安排，一般是两小时一次，并以pool为单位安排车厢，在同一个pool的应用中必须在同一个车次的同一个车厢进行
		发布。实际的情况是：每一个应用在发布前需要"买票"，即申请和备案的过程，然后被分配到某个"车次"并与在同一pool中且需要发布的其他应用形成一个
		"车厢"，当达到规定的发布时间时，该"车厢"内的所有应用，会以灰度的方式进行发布。

			缺点：
				1.即使提前做好了发布准备，但是没达到规定时间，也只能等待；
				2.如果错过了某个发布时间，只能等下一次；
				3.如果在发布过程中，同一个"车厢"内的某个应用发布失败，则整个车厢都会发布失败，需要整体回滚。

		2.Tars 发布流程
			1.Smoking 的过程为，拉出堡垒机->下载发布的包->安装应用程序->点火检查。当点火通过后，则认为发布成功。
			2.Baking，是指用户手动拉入的过程，在此之前，应该先进行堡垒测试。
			3.在经过Baking后，说明堡垒机已经接入了正式流量，开发人员在此阶段应该关注应用的监控系统，确认是否有异常，如果有异常，则回滚堡垒机，
			否则进行接下来的Rolling操作。
			4.Rolling的过程就是批量部署Group内的机器。在部署时将Group分成多个批次，用户可以设置每一个批次的数量，并配置批次内的机器为并发执行
			部署，这个做法既能保证部署的灰度进行，又能保证部署的速度不会太慢。
			5.在Rolling的过程中，与堡垒机部署的不同在于拉入过程是自动的，只有Verify正确才会认为部署成功。如果有个别机器部署失败，不会影响到整个
			部署流程，但是当数量超过一定比例，就会停止部署，我们称之为"刹车"。
			6.除此之外，发布系统还允许对其他依赖的系统进行降级。