Docker容器项目实战高职PPT完整全套教学课件

Docker容器项目实战第一章PaaS云平台基本管理任务1.1-1：熟悉PaaS云平台

全套PPT课件任务导入和职业能力要求2本公司为电商公司，目前自行开发APP软件、搭建并维护服务器平台。由于公司规模急剧扩大，软件开发复杂度越来越高、服务器硬件投入越来越多、系统运维难度越来越大。现计划将APP开发和部署全面迁移到云平台上，以提高效率、降低成本，需了解云平台的基本情况任务导入职业能力要求熟悉云计算服务体系三种类型的定义、特点和应用场景了解PaaS发展历程熟悉PaaS的基本实现方法熟悉容器云的基本情况一、熟悉云计算服务体系我们知道TCP/IP有五层协议，协议的出现和规定就是让标准能够统一，这样无论是开发者、使用者、网络设备厂商都能按照这公认的协议来学习和生产。如果没有协议，必将会乱套，你搞你的标准，我搞我的标准云计算服务体系也采用分层定义的标准：包括IaaS、PaaS、SaaS三个层次，每个层次之上都可以构建相应的IT系统，提供特定的服务；传统的IT系统需要提供所有层次的服务3一、熟悉云计算服务体系IaaS：Infrastructure-as-a-Service（基础设施即服务）通过提供在线的高级API服务，底层基础架构细节都不会向上体现，比如服务器位置，网络布线，数据分区、扩展、备份，安全性等。底层的计算、网络、存储等资源都将通过虚拟化技术来整体管理和配置，这些虚拟化技术有Xen，KVM，VMwareESX/ESXi，Hyper-V，Ceph，SDN等IaaS即传统的计算、网络、存储资源全部做虚拟化。之前需直接管理服务器、交换机、存储；虚拟化后只需通过终端操作虚拟化管理平台，管理这些硬件虚拟出来的VM、虚拟交换机、路由器、存储池4一、熟悉云计算服务体系PaaS：Platform-as-a-Service（平台即服务）提供平台允许客户开发、运行和管理应用程序，而无需考虑应用程序的构建和维护工作。可细分为aPaaS（applicationplatformasaservice，应用部署和运行平台)、iPaaS（integrationasaservice，集成平台）等两大类PaaS是建立在完善的IaaS之上的，用户使用PaaS平台，只关心如何去使用PaaS平台给予的资源，而这些资源的创建、维护工作，使用者完全不用关心5一、熟悉云计算服务体系SaaS：Software-as-a-Service（软件即服务）SaaS是一种软件交付模式。在这种交付模式中云端集中式托管软件及其相关的数据，软件仅需透过互联网，而不用通过安装即可使用。用户通常使用精简客户端经由一个网页浏览器来访问软件SaaS级云服务供应商可通过网页控制台提供CRM、ERP、OA等软件系统。传统的软件，无论是BS架构或者CS架构，SaaS供应商都能够提供（或者额外提供）。用户只关心使用SaaS提供的软件应用，数据存储、软件维护、安全等事情都交给云厂商处理和负责6一、熟悉云计算服务体系采用IaaS云服务时，底层的网络、服务器和存储硬件的安装管理均有云服务商提供。云服务商根据用户配置要求提供各种虚拟机。用户只需在云系统提供的虚拟机中安装维护操作系统、中间件和应用运行环境；部署应用软件、维护应用数据采用PaaS云服务时，云服务商不仅负责网络、服务器和存储硬件的安装管理，还负责虚拟机中操作系统、中间件和应用的运行环境的安装维护；云服务商向用户提供的是应用软件开发部署的全套软硬件环境。用户只需在此环境中开发部署应用软件、维护应用数据采用SaaS云服务时，云服务商负责传统应用构建的所有内容。用户只需根据自身需求订购应用服务7二、了解PaaS发展历程82007Salesforce最早发布，支持第三方客户在S上开发和部署定制软件，使用元数据驱动的方式来开发和管理应用2008GAE2011Beanstalk2014CloudFoundry2013Docker2015KubernetesGoogle发布GAE(GoogleAppEngine)，争夺独立开发者和创业公司的市场。GAE使用容器来部署应用，提供简化的用户体验AWS发布其官方PaaS平台Beanstalk，基于虚拟机完成应用的自动部署和运维，和自动弹性伸缩的功能。区别于之前基于Linux容器技术的PaaSDocker是PaaS提供商dotCloud开源的一个基于LXC的高级容器引擎。利用AUFS技术第一次将容器实例镜像化，实现突破性的创新CF最初由VMWare开发，于2014年转入Pivotal。它是开源的和免费的，支持多种编程语言和开发框架，和多种服务类型K8S来源于谷歌内部的Borg系统，2015年迭代到v1.0并正式对外公布。是一个全新的基于容器技术的分布式架构解决方案三、熟悉PaaS的基本实现方法容器与虚拟机的基本区别传统的虚拟机技术是虚拟出一套硬件后，在上面运行一套完整的操作系统，在该系统上再运行所需的各种应用程序docker容器技术不需虚拟出完整的硬件和操作系统，容器内的应用程序进程直接运行于物理计算机操作系统的内核上，容器内没有自己的内核，也没有自己的虚拟硬件9三、熟悉PaaS的基本实现方法基于虚拟机的PaaS（Beanstalk为例）负载均衡层（ELB）：该层需要将用户的请求映射到对应的服务器实例；当应用实例扩容时，动态将调整的服务器实例注册到对应的域名上，以完成分流Web服务器层：目前ElasticBean支持Java、Python和PHP等多种编程语言，尽量为编程人员提供多样性的选择，保持开放性在服务后端，Beanstalk依托于AWS本身的服务生态系统为应用提供服务，比如RDS、S3、DynamoDB等10三、熟悉PaaS的基本实现方法基于容器的PaaS（CloudFoundry为例）路由模块(Router)：该模块基于ngnix，在ngnix技术基础上提供动态注册的功能。在部署时，使用router集群同时部署海量应用实例CF的应用容器基于warden技术，warden也是基于LXC技术，但是使用c和ruby作了一层简单的封装servicebroker：集成各种资源服务，如mongo、mysql、rabbitmq和redis等消息总线NATS/GNATS：CF使用消息总线来完成应用之间的通讯11四、熟悉容器云的基本情况容器为用户打开了一扇通往新世界的大门，真正进入容器的世界后，却发现新的生态系统如此庞大。在生产使用时，无论是个人还是企业，都会提出更复杂的需求我们需要众多跨主机的容器协同工作，需要支持各种类型的工作负载，企业级应用开发更是需要基于容器技术，实现支持多人协作的持续集成、持续交付平台。即使Docker只需一条命令便可启动一个容器，一旦试图将其推广到软件开发和生产环境中，麻烦便层出不穷，容器相关的网络、存储、集群、高可用等就是不得不面对的问题。从容器到容器云的进化应运而生容器云以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建，发布和运行分布式应用的平台。当容器云专注于资源共享与隔离、容器编排与部署，它更接近传统的IaaS；当容器云渗透到应用支撑与运行时环境时，它更接近与传统的PaaS12四、熟悉容器云的基本情况Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用和依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows系统上。Kubernetes是一个针对容器应用，进行自动部署、弹性伸缩和管理的开源系统，主要功能是生产环境的容器编排Docker+Kubernetes构成容器云已成为主流的PaaS解决方案，推动云计算PAAS层的完善和普及13+Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.2-1：熟悉云原生开发的基本概念和要求

任务导入和职业能力要求16PaaS云平台的引入，将大大改变公司现有的APP软件开发和部署模式，需熟悉云原生开发的基本情况任务导入职业能力要求熟悉云原生开发的基本概念了解云原生开发的基本要求一、熟悉云原生开发的基本概念云原生（CloudNative）是一种构建和运行应用程序的方法，是一套技术体系和方法论Cloud表示应用程序位于云中，而不是传统的数据中心Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势1720132015201520182017Pivotal公司首次提出云原生（CloudNative）概念MattStine定义云原生架构的5大特征云原生计算基金会（CNCF）成立，明确云原生定义MattStine将云原生架构归纳为6大特质CNCF更新云原生的定义一、熟悉云原生开发的基本概念云原生的基本特征2015，MattStine《迁移到云原生架构》：12要素、微服务、自敏捷架构、基于API协作、扛脆弱性2015，云原生计算基金会（CNCF）：容器化封装+自动化管理+面向微服务2017，MattStine：模块化、可观察、可部署、可测试、可替换、可处理2017，Pivotal官网：

DevOps+持续交付+微服务+容器2018，云原生计算基金会（CNCF）：增加服务网格（ServiceMesh）、声明式APIDevOps+持续交付+微服务+容器18一、熟悉云原生开发的基本概念云原生开发与传统企业应用软件开发的差异19项目云原生开发传统软件开发1、编程语言以网络为中心的语言：HTML，CSS，Java，JavaScript，.Net，Go，Node.js，PHP，Python和Ruby传统语言：C/C++，C＃，企业级Java等2、可更新性应用程序始终是最新的，且始终可用应用程序需要更新，通常由供应商按需提供，在安装更新时需要停机3、弹性应用程序通过在峰值期间增加的资源来利用云平台的弹性应用程序无法动态扩展4、多租户应用程序在虚拟化环境中工作，并与其他应用程序共享资源许多本地部署应用程序在虚拟化环境中不能正常工作5、连接的资源适应网络、存储甚至数据库技术的变化，以允许应用程序在云中运行应用程序与网络资源的连接相当严格，例如网络，安全性，权限和存储。许多资源需要硬编码，如果移动或更改了任何内容就会中断一、熟悉云原生开发的基本概念云原生开发与传统企业应用软件开发的差异20项目云原生开发传统软件开发6、服务中断时间云中部署存在比本地部署更大的冗余，如果云供应商遭受中断，则另一个冗余区域可快速消除中断可提前准备好故障转移，但如果服务器出现故障，应用程序可能会崩溃7、自动化大部分都是自动化，以实现可重复性、自助服务、敏捷性、可扩展性以及审计和控制应用程序必须手动管理8、模块化设计更加模块化，许多功能分解为微服务；允许在不需要时关闭，更新推广到模块而不是整个应用程序往往在设计上是单一的，会将一些工作卸载到库中，但最终是一个包含大量子程序的大应用程序9、无状态云的松耦合特性意味着应用程序与基础架构无关，应用程序将其状态存储在数据库或其他外部实体中大多数应用程序是有状态的，意味着它们会在运行代码的基础架构上存储应用程序的状态。在添加服务器资源时可能会破坏应用程序二、了解云原生开发的基本要求12要素“12要素”英文全称是TheTwelve-FactorApp，描述了软件应用原型，诠释了使用原生云应用架构的原因通过强化详细配置和规范，类似Rails的基于“约定优于配置”的原则，应用于大规模软件生产实践基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用21二、了解云原生开发的基本要求云原生开发框架为抓住商业机会，业务需要快速迭代，不断试错，因此企业需要依赖拥有持续交付的能力（包括技术需求和产品的需求）效率低下的巨石型架构无法满足，演变出微服务架构，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖满足12要素原则的来规范完成系统被分成了几十个甚至几百个服务组件，需要借助DevOps才能很好地满足业务协作和发布等流程DevOps的有效实施需要依赖敏捷的基础设施服务，即云计算模式来满足整体要求22二、了解云原生开发的基本要求云原生应用设计原则高可用设计（DesignforAvailability），依据应用业务需求，高可用分为不同级别，比如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的高可用，云原生应用应该根据业务的可用性要求设计不同级别的架构支持可扩展设计（DesignforScale），所有应用的设计是无状态的，使得业务天生具有扩展性，在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容，满足业务需求快速失败设计（DesignforFailure），即包括系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能宕机，还有后端有状态服务的系统能力可能有瓶颈，总之在发生异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着23二、了解云原生开发的基本要求云原生开发要点不要试图将旧的本地部署应用程序直接并迁移到云端。试图利用现有的应用程序，特别是单一的遗留应用程序，并将它们转移到云基础架构上将无法利用必要的云原生功能可以将新的云原生应用程序放入新的云基础架构中，或者通过拆分现有的单块应用来从头开始使用云原生原则重构需要放弃旧的开发方法。不会再用瀑布模型，甚至敏捷开发可能还不够。须采用新的云原生方法，如最小可行产品（MVP）开发，多变量测试，快速迭代，以及在DevOps模型中跨组织边界密切合作24Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.2-2：熟悉云原生开发的技术要点

任务导入和职业能力要求27PaaS云平台的引入，将大大改变公司现有的APP软件开发和部署模式，需熟悉云原生开发的基本情况任务导入职业能力要求熟悉微服务的技术要点熟悉容器化的技术要点熟悉DevOps的技术要点熟悉持续交付的技术要点一、熟悉微服务的技术要点微服务：“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的RestfulAPI).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行架构” MartinFowler的博客28一、熟悉微服务的技术要点微服务：微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务；与微服务相对的是单体应用几乎每个云原生的定义都包含微服务，微服务的理论基础是“康威定律”29X轴：运行多个负载均衡器之后的运行实例Y轴：将应用进一步分解为微服务（分库）Z轴：大数据量时，将服务分区（分表）一、熟悉微服务的技术要点微服务：30微服务架构的优点微服务架构的缺点提升开发交流，每个服务足够内聚，足够小，代码容易理解服务独立测试、部署、升级、发布按需定制的DFX，资源利用率高，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上每个服务按需要选择HA模式，选择接受服务的实例个数容易扩大开发团队，可以针对每个服务（service）组建开发团队提高容错性（faultisolation），一个服务的内存泄露并不会让整个系统瘫痪新技术的应用，系统不会被长期限制在某个技术栈微服务提高了系统的复杂度开发人员要处理分布式系统的复杂性服务之间的分布式通信问题服务的注册与发现问题服务之间的分布式事务问题数据隔离再来的报表处理问题服务之间的分布式一致性问题服务管理的复杂性，服务的编排不同服务实例的管理二、熟悉容器化的技术要点容器化：Docker是应用最为广泛的容器引擎，基于LXC技术，在思科谷歌等公司的基础设施中大量使用容器化为微服务提供实施保障，起到应用隔离作用K8S是容器编排系统，用于容器管理，容器间的负载均衡31三、熟悉DevOps的技术要点DevOps（开发运维一体化）：DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力从定义来看，其实devops就是为了让开发、运维

和QA可以高效协作的流程，可看作三者的交集：开发（软件工程）技术运营质量保障（QA）32三、熟悉DevOps的技术要点DevOps：DevOps对应用程序发布的影响减少变更范围与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长加强发布协调靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电子数据表、电话会议和企业门户等协作工具来确保所有相关人员理解变更的内容并全力合作自动化强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。大大提升了发布频率（通常以“天”或“周”为单位）33三、熟悉DevOps的技术要点DevOps：DevOps工具链编码：代码开发和审阅，版本控制工具、代码合并工具构建：持续集成工具、构建状态统计工具测试：通过测试和结果确定绩效的工具打包：成品仓库、应用程序部署前暂存发布：变更管理、发布审批、发布自动化配置：基础架构配置和部署，基础架构即代码工具监视：应用程序性能监视、最终用户体验34三、熟悉DevOps的技术要点DevOps：硬性要求：工具上的准备35代码管理（SCM）GitHub、GitLab、BitBucket、SubVersion构建工具Ant、Gradle、maven自动部署Capistrano、CodeDeploy持续集成（CI）Bamboo、Hudson、Jenkins配置管理Ansible、Chef、Puppet、SaltStack、ScriptRockGuardRail容器Docker、LXC、第三方厂商如AWS编排Kubernetes、Core、ApacheMesos、DC/OS服务注册与发现Zookeeper、etcd、Consul脚本语言python、ruby、shell日志管理ELK、Logentries三、熟悉DevOps的技术要点DevOps：硬性要求：工具上的准备36系统监控Datadog、Graphite、Icinga、Nagios性能监控AppDynamics、NewRelic、Splunk压力测试JMeter、BlazeMeter、loader.io预警PagerDuty、pingdom、厂商自带如AWSSNSHTTP加速器Varnish消息总线ActiveMQ、SQS应用服务器Tomcat、JBossWeb服务器Apache、Nginx、IIS数据库MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库项目管理（PM）Jira、Asana、Taiga、Trello、Basecamp、PivotalTracker三、熟悉DevOps的技术要点DevOps：软性需求：文化和人DevOps成功与否，公司组织是否利于协作是关键协作存在于开发人员和运维人员之间、业务人员与开发人员之间；通过良好沟通互相学习，从而拥有更高的生产力，软件产品得到更好的一致性和更高的质量37四、熟悉持续交付的技术要点持续交付：持续交付（Continuousdelivery，CD）是一种软件工程方法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险38持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑四、熟悉持续交付的技术要点持续交付：持续发布的基本方法蓝绿部署在部署的过程中，我们的应用始终在线。新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，我们可以在任何时间回滚到老版本39四、熟悉持续交付的技术要点持续交付：持续发布的基本方法滚动部署一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本优点：相对于蓝绿部署，更加节约资源—它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级缺点：(1)没有一个确定无错误的环境 (2)修改了现有的环境(3)难以回滚。如在某一次发布中需更新100个实例，每次更新10个实例，每次部署需5分钟；当滚动发布到第80个实例时，发现了问题需要回滚，这个回滚将是一个痛苦而漫长的过程(4)因是逐步更新，上线代码时，会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题40四、熟悉持续交付的技术要点持续交付：持续发布的基本方法灰度发布/金丝雀发布灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如用户对B没有反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度而我们平常所说的金丝雀部署也就是灰度发布的一种方式 41Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.2-3：了解云原生开发的12要素

任务导入和职业能力要求44PaaS云平台的引入，将大大改变公司现有的APP软件开发和部署模式，需熟悉云原生开发的基本情况任务导入职业能力要求了解云原生开发的12要素一、了解云原生开发的12要素12要素“12要素”英文全称是TheTwelve-FactorApp，描述了软件应用原型，诠释了使用原生云应用架构的原因通过强化详细配置和规范，类似Rails的基于“约定优于配置”的原则，应用于大规模软件生产实践基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用45一、了解云原生开发的12要素1、基准代码每一个部署的应用都在版本控制代码库中被追踪。在多个部署环境中，会有多种部署实例，单个应用只有一份代码库，多份部署相当于运行了该应用的多个实例，比如开发环境一个实例，测试环境、生产环境都有一个实例实际上，在云计算架构中，所有的基础设施都是代码配置，即InfrastructureasCode（IaC），整个应用通过配置文件就可以编排出来，而不再需要手工的干预，做到基础服务也是可以追踪的46一、了解云原生开发的12要素2、依赖应用程序不会隐式依赖系统级的类库，通过依赖清单声明所有依赖项，通过依赖隔离工具确保程序不会调用系统中存在，但清单中未声明依赖项，并统一应用到生产和开发环境。比如通过合适的工具（例如Maven、Bundler、NPM），应用可以很清晰地对部署环境公开和隔绝依赖性，而不是模糊地对部署环境产生依赖性在容器应用中，所有应用的依赖和安装都是通过DockerFile来完成声明的，通过配置能明确把依赖关系，包括版本都明确地图形化展示出来，不存在黑盒47一、了解云原生开发的12要素3、配置环境变量是一种清楚、容易理解和标准化的配置方法，将应用的配置存储于环境变量中，保证配置排除在代码之外，或者其他可能在部署环境（例如研发、展示、生产）之间区别的任何代码，可以通过操作系统级的环境变量来注入实例根据不同的环境配置运行在不同的环境中，此外，实现配置即代码，在云环境中，无论是统一的配置中心还是分布式的配置中心都有好的实践方式，比如Docker的环境变量使用4、后端服务不用区别对待本地或第三方服务，统一把依赖的后端作为一种服务来对待，例如数据库或者消息代理，作为附加资源，同等地在各种环境中被消耗。比如在云架构的基础服务中，计算、网络、存储资源都可以看作是一种服务去对待使用即可，不用区分是远程还是本地的48一、了解云原生开发的12要素5、构建、发布、运行应用严格区分构建、发布、运行这3个阶段。3个阶段是严格分开的，一个阶段对应做一件事情，每个阶段有很明确的实现功能。云原生应用的构建流程可以把发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。在云原生应用中，基于容器的Build-Ship-Run和这3个阶段完全吻合，也是Docker对本原则的最佳实践6、进程进程必须无状态且无共享，即云应用以一个或多个无状态不共享的程序运行。任何必要状态都被服务化到后端服务中（缓存、对象存储等）所有的应用在设计时就认为随时随地会失败，面向失败而设计，因此进程可能会被随时拉起或消失，特别是在弹性扩容的阶段49一、了解云原生开发的12要素7、端口绑定不依赖于任何网络服务器就可以创建一个面向网络的服务，每个应用的功能都很齐全，通过端口绑定对外提供所有服务，比如Web应用通过端口绑定（Portbinding）来提供服务，并监听发送至该端口的请求（包括HTTP）在容器应用中，应用统一通过暴露端口来服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现而服务8、并发进程可以看作一等公民，并发性即可以依靠水平扩展应用程序来实现，通过进程模型进行扩展，并且具备无共享、水平分区的特性在互联网的服务中，业务的爆发性随时可能发生，因此不太可能通过硬件扩容来随时提供扩容服务，需要依赖横向扩展能力进行扩容50一、了解云原生开发的12要素9、易处理所有应用的架构设计都需要支持能随时销毁的特点，和状态的无关性保持一致，允许系统快速弹性扩展、改变部署及故障恢复等在云环境中，由于业务的高低峰值经常需要能实现快速灵活、弹性的伸缩应用，以及不可控的硬件因素等，应用可能随时会发生故障，因此应用在架构设计上需要尽可能无状态，应用能随时随地拉起，也能随时随地销毁，同时保证进程最小启动时间和架构的可弃性，也可以提供更敏捷的发布及扩展过程10、环境等价必须缩小本地与线上差异，确保环境的一致性，保持研发、测试和生产环境尽可能相似，这样可以提供应用的持续交付和部署服务在容器化应用中，通过文件构建的环境运行能做到版本化，因此保证各个不同环境的差异性，同时还能大大减少环境不同带来的排错等成本沟通问题51一、了解云原生开发的12要素11、日志每一个运行的进程都会直接标准输出（stdout）和错误输出（stderr）事件流，还可以将日志当作事件流作为数据源，通过集中服务，执行环境收集、聚合、索引和分析这些事件日志是系统运行状态的部分体现，无论在系统诊断、业务跟踪还是后续大数据服务的必要条件中，Docker提供标准的日志服务，用户可以根据需求做自定义的插件开发来处理日志12、管理进程管理或维护应用的运行状态是软件维护的基础部分，比如数据库迁移、健康检查、安全巡检等，在与应用长期运行的程序相同环境中，作为一次性程序运行在应用架构模式中，比如Kubernetes里面的Pod资源或者dockerexec，可以随着其他的应用程序一起发布或在出现异常诊断时能通过相关的程序去管理其状态52Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.3-1：熟悉微服务架构（一）

任务导入和职业能力要求55PaaS云平台需要承载公司基于云原生开发的APP应用，云平台的建设和运维，首先要了解APP应用的微服务架构任务导入职业能力要求熟悉微服务架构的基本原理（基本的微服务架构）一、熟悉微服务架构的基本原理要理解微服务，首先要理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。最初的需求几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。56原文链接：

/skabyy/p/11396571.html一、熟悉微服务架构的基本原理最初的需求我们整理一下功能清单：网站用户注册、登录功能商品展示下单管理后台用户管理商品管理订单管理由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。57小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。一、熟悉微服务架构的基本原理随着业务发展……好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。在竞争的压力下，小明小皮决定开展一些营销手段：开展促销活动。比如元旦全场打折，春节买二送一，情人节狗粮优惠券等等。拓展渠道，新增移动端营销。除了网站外，还需要开发移动端APP，微信小程序等。精准营销。利用历史数据对用户进行分析，提供个性化服务。……58一、熟悉微服务架构的基本原理随着业务发展……这些活动都需要程序开发的支持。小明拉了同学小红加入团队。小红负责数据分析以及移动端相关开发。小明负责促销活动相关功能的开发。因为开发任务比较紧迫，小明小红没有好好规划整个系统的架构，随便拍了拍脑袋，决定把促销管理和数据分析放在管理后台里，微信和移动端APP另外搭建。通宵了几天后，新功能和新应用基本完工。59一、熟悉微服务架构的基本原理随着业务发展……这一阶段存在很多不合理的地方：网站和移动端应用有很多相同业务逻辑的重复代码。数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。单个应用为了给其他应用提供接口，渐渐地越改越大，包含了很多本来就不属于它的逻辑。应用边界模糊，功能归属混乱。管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。数据库表结构被多个应用依赖，无法重构和优化。所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码，或者修改了一个功能后，另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响，所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的，或者随便放个地方但是都不维护。60一、熟悉微服务架构的基本原理随着业务发展……尽管有着诸多问题，但也不能否认这一阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重的任务容易使人陷入局部、短浅的思维方式，从而做出妥协式的决策。在这种架构中，每个人都只关注在自己的一亩三分地，缺乏全局的、长远的设计。长此以往，系统建设将会越来越困难，甚至陷入不断推翻、重建的循环。61一、熟悉微服务架构的基本原理是时候做出改变了幸好小明和小红是有追求有理想的好青年。意识到问题后，小明和小红从琐碎的业务需求中腾出了一部分精力，开始梳理整体架构，针对问题准备着手改造。要做改造，首先你需要有足够的精力和资源。如果你的需求方（业务人员、项目经理、上司等）很强势地一心追求需求进度，以致于你无法挪出额外的精力和资源的话，那么你可能无法做任何事……62一、熟悉微服务架构的基本原理是时候做出改变了在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。小明和小红整理了网上超市的业务逻辑，抽象出公用的业务能力，做成几个公共服务：用户服务商品服务促销服务订单服务数据分析服务各个应用后台只需从这些服务获取所需的数据，从而删去了大量冗余的代码，就剩个轻薄的控制层和前端。63一、熟悉微服务架构的基本原理是时候做出改变了这个阶段只是将服务分开了，数据库依然是共用的，所以一些烟囱式系统的缺点仍然存在：数据库成为性能瓶颈，并且有单点故障的风险。数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整。如果一直保持共用数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此小明和小红一鼓作气，把数据库也拆分了。所有持久化层相互隔离，由各个服务自己负责。另外，为了提高系统的实时性，加入了消息队列机制。64一、熟悉微服务架构的基本原理是时候做出改变了完全拆分后各个服务可以采用异构的技术。比如数据分析服务可以使用数据仓库作为持久化层，以便于高效地做一些统计计算；商品服务和促销服务访问频率比较大，因此加入了缓存机制等。还有一种抽象出公共逻辑的方法是把这些公共逻辑做成公共的框架库。这种方法可以减少服务调用的性能损耗。但是这种方法的管理成本非常高昂，很难保证所有应用版本的一致性。数据库拆分也有一些问题和挑战：比如说跨库级联的需求，通过服务查询数据颗粒度的粗细问题等。但是这些问题可以通过合理的设计来解决。总体来说，数据库拆分是一个利大于弊的。65一、熟悉微服务架构的基本原理是时候做出改变了微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人（一般是能力比较强或者比较热心的人）做到他负责的应用里面。在后者的情况下，这个人在负责自己应用之外，还要额外负责给别人提供这些公共的功能——而这个功能本来是无人负责的，仅仅因为他能力较强/比较热心，就莫名地背锅（这种情况还被美其名曰能者多劳）。结果最后大家都不愿意提供公共的功能。长此以往，团队里的人渐渐变得各自为政，不再关心全局的架构设计。从这个角度上看，使用微服务架构同时也需要组织结构做相应的调整。所以说做微服务改造需要管理者的支持。改造完成后，小明和小红分清楚各自的锅。两人十分满意，一切就像是麦克斯韦方程组一样漂亮完美。然而……66Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.3-2：熟悉微服务架构（二）

任务导入和职业能力要求69PaaS云平台需要承载公司基于云原生开发的APP应用，云平台的建设和运维，首先要了解APP应用的微服务架构任务导入职业能力要求熟悉微服务架构的基本原理（大规模应用时的问题应对）一、熟悉微服务架构的基本原理没有银弹春天来了，万物复苏，又到了一年一度的购物狂欢节。眼看着日订单数量蹭蹭地上涨，小皮小明小红喜笑颜开。可惜好景不长，乐极生悲，突然嘣的一下，系统挂了。以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。小明一个台机器一台机器地查看日志，一个服务一个服务地手工调用。经过十几分钟的查找，小明终于定位到故障点：促销服务由于接收的请求量太大而停止响应了。其他服务都直接或间接地会调用促销服务，于是也跟着宕机了。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。其实在节前，小明和小红是有做过请求量评估的。按照预计，服务器资源是足以支持节日的请求量的，所以肯定是哪里出了问题。不过形势紧急，随着每一分每一秒流逝的都是白花花的银子，因此小明也没时间排查问题，当机立断在云上新建了几台虚拟机，然后一台一台地部署新的促销服务节点。几分钟的操作后，系统总算是勉强恢复正常了。整个故障时间内估计损失了几十万的销售额，三人的心在滴血……70原文链接：

/skabyy/p/11396571.html一、熟悉微服务架构的基本原理没有银弹事后，小明简单写了个日志分析工具（量太大了，文本编辑器几乎打不开，打开了肉眼也看不过来），统计了促销服务的访问日志，发现在故障期间，商品服务由于代码问题，在某些场景下会对促销服务发起大量请求。这个问题并不复杂，小明手指抖一抖，修复了这个价值几十万的Bug。问题解决了，但谁也无法保证不会再发生类似的其他问题。微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新问题：微服务架构整个应用分散成多个服务，定位故障点非常困难。稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。服务数量非常多，部署、管理的工作量很大。开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。71一、熟悉微服务架构的基本原理没有银弹小明小红痛定思痛，决心好好解决这些问题。对故障的处理一般从两方面入手，一方面尽量减少故障发生的概率，另一方面降低故障造成的影响。72一、熟悉微服务架构的基本原理监控-发现故障的征兆在高并发分布式的场景下，故障经常是突然间就雪崩式爆发。所以必须建立完善的监控体系，尽可能发现故障的征兆。微服务架构中组件繁多，各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。73一、熟悉微服务架构的基本原理监控-发现故障的征兆大部分组件都不需要自己动手开发，网络上有开源组件。小明下载了RedisExporter和MySQLExporter，这两个组件分别提供了Redis缓存和MySQL数据库的指标接口。微服务则根据各个服务的业务逻辑实现自定义的指标接口。然后小明采用Prometheus作为指标采集器，Grafana配置监控界面和邮件告警。这样一套微服务监控系统就搭建起来了：74一、熟悉微服务架构的基本原理定位问题-链路跟踪在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。我们用一个Istio文档里的链路跟踪例子来看看效果：75图片来自Istio文档一、熟悉微服务架构的基本原理定位问题-链路跟踪从图中可以看到，这是一个用户访问productpage页面的请求。在请求过程中，productpage服务顺序调用了details和reviews服务的接口。而reviews服务在响应过程中又调用了ratings的接口。整个链路跟踪的记录是一棵树：76一、熟悉微服务架构的基本原理定位问题-链路跟踪要实现链路跟踪，每次服务调用会在HTTP的HEADERS中记录至少记录四项数据：traceId：traceId标识一个用户请求的调用链路。具有相同traceId的调用属于同一条链路。spanId：标识一次服务调用的ID，即链路跟踪的节点ID。parentId：父节点的spanId。requestTime&responseTime：请求时间和响应时间。另外，还需要调用日志收集与存储的组件，以及展示链路调用的UI组件。77一、熟悉微服务架构的基本原理定位问题-链路跟踪以上只是一个极简的说明，关于链路跟踪的理论依据可详见Google的Dapper了解了理论基础后，小明选用了Dapper的一个开源实现Zipkin。然后手指一抖，写了个HTTP请求的拦截器，在每次HTTP请求时生成这些数据注入到HEADERS，同时异步发送调用日志到Zipkin的日志收集器中。这里额外提一下，HTTP请求的拦截器，可以在微服务的代码中实现，也可以使用一个网络代理组件来实现（不过这样子每个微服务都需要加一层代理）。链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。78一、熟悉微服务架构的基本原理分析问题-日志分析日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的UI组件：79一、熟悉微服务架构的基本原理分析问题-日志分析小明调查了一下，使用了大名鼎鼎地ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。Elasticsearch：搜索引擎，同时也是日志的存储。Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。最后还有一个小问题是如何将日志发送到Logstash。一种方案是在日志输出的时候直接调用Logstash接口将日志发送过去。这样一来又（咦，为啥要用“又”）要修改代码……于是小明选用了另一种方案：日志仍然输出到文件，每个服务里再部署个Agent扫描日志文件然后输出给Logstash。80一、熟悉微服务架构的基本原理网关-权限控制，服务治理拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关。在调用者和被调用者中间加一层网关，每次调用时进行权限校验。另外，网关也可以作为一个提供服务接口文档的平台。81一、熟悉微服务架构的基本原理网关-权限控制，服务治理使用网关有一个问题就是要决定在多大粒度上使用：最粗粒度的方案是整个微服务一个网关，微服务外部通过网关访问微服务，微服务内部则直接调用；最细粒度则是所有调用，不管是微服务内部调用或者来自外部的调用，都必须通过网关。折中的方案是按照业务领域将微服务分成几个区，区内直接调用，区间通过网关调用。由于整个网上超市的服务数量还不算特别多，小明采用的最粗粒度的方案：82一、熟悉微服务架构的基本原理服务注册与发现-动态扩容前面的组件，都是旨在降低故障发生的可能性。然而故障总是会发生的，所以另一个需要研究的是如何降低故障产生的影响。最粗暴的（也是最常用的）故障处理策略就是冗余。一般来说，一个服务都会部署多个实例，这样一来能够分担压力提高性能，二来即使一个实例挂了其他实例还能响应。冗余的一个问题是使用几个冗余？这个问题在时间轴上并没有一个切确的答案。根据服务功能、时间段的不同，需要不同数量的实例。比如在平日里，可能4个实例已经够用；而在促销活动时，流量大增，可能需要40个实例。因此冗余数量并不是一个固定的值，而是根据需要实时调整的。一般来说新增实例的操作为：部署新实例将新实例注册到负载均衡或DNS上操作只有两步，但如果注册到负载均衡或DNS的操作为人工操作的话，那事情就不简单了。想想新增40个实例后，要手工输入40个IP的感觉……83一、熟悉微服务架构的基本原理服务注册与发现-动态扩容解决这个问题的方案是服务自动注册与发现。首先，需要部署一个服务发现服务，它提供所有已注册服务的地址信息的服务。DNS也算是一种服务发现服务。然后各个应用服务在启动时自动将自己注册到服务发现服务上。并且应用服务启动后会实时（定期）从服务发现服务同步各个应用服务的地址列表到本地。服务发现服务也会定期检查应用服务的健康状态，去掉不健康的实例地址。这样新增实例时只需要部署新实例，实例下线时直接关停服务即可，服务发现会自动检查服务实例的增减。84一、熟悉微服务架构的基本原理服务注册与发现-动态扩容服务发现还会跟客户端负载均衡配合使用。由于应用服务已经同步服务地址列表在本地了，所以访问微服务时，可以自己决定负载策略。甚至可以在服务注册时加入一些元数据（服务版本等信息），客户端负载则根据这些元数据进行流量控制，实现A/B测试、蓝绿发布等功能。服务发现有很多组件可以选择，比如说Zookeeper、Eureka、Consul、Etcd等。不过小明觉得自己水平不错，想炫技，于是基于Redis自己写了一个……85Q&ADocker容器项目实战第一章PaaS云平台基本管理任务1.3-3：熟悉微服务架构（三）

任务导入和职业能力要求88PaaS云平台需要承载公司基于云原生开发的APP应用，云平台的建设和运维，首先要了解APP应用的微服务架构任务导入职业能力要求熟悉微服务架构的基本原理（高级功能与发展趋势）一、熟悉微服务架构的基本原理熔断、服务降级、限流熔断当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。89图片来自《微服务设计》原文链接：

/skabyy/p/11396571.html一、熟悉微服务架构的基本原理熔断、服务降级、限流服务降级当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。90限流一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。一、熟悉微服务架构的基本原理测试微服务架构下，测试分为三个层次：端到端测试：覆盖整个系统，一般在用户界面进行测试。服务测试：针对服务接口进行测试。单元测试：针对代码单元进行测试。三种测试从上到下实施的容易程度递增，但是测试效果递减。端到端测试最费时费力，但是通过测试后我们对系统最有信心。单元测试最容易实施，效率也最高，但是测试后不能保证整个系统没有问题。91一、熟悉微服务架构的基本原理测试由于端到端测试实施难度较大，一般只对核心功能做端到端测试。一旦端到端测试失败，则需要将其分解到单元测试：则分析失败原因，然后编写单元测试来重现这个问题，这样未来我们便可以更快地捕获同样的错误。92一、熟悉微服务架构的基本原理测试服务测试的难度在于服务会经常依赖一些其他服务。这个问题可以通过MockServer解决：单元测试大家都很熟悉了。我们一般会编写大量的单元测试（包括回归测试）尽量覆盖所有代码。93一、熟悉微服务架构的基本原理微服务框架指标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码。如果让每个应用服务自己实现是非常耗时耗力的。基于DRY的原则，小明开发了一套微服务框架，将与各个组件对接的代码和另外一些公共代码抽离到框架中，所有的应用服务都统一使用这套框架进行开发。使用微服务框架可以实现很多自定义的功能。甚至可以将程序调用堆栈信息注入到链路跟踪，实现代码级别的链路跟踪。或者输出线程池、连接池的状态信息，实时监控服务底层状态。使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。94一、熟悉微服务架构的基本原理另一条路-ServiceMesh另一种抽象公共代码的方法是直接将这些代码抽象到一个反向代理组件。每个服务都额外部署这个代理组件，所有出站入站的流量都通过该组件进行处理和转发。这个组件被称为Sidecar。Sidecar不会产生额外网络成本。Sidecar会和微服务节点部署在同一台主机上并且共用相同的虚拟网卡。所以sidecar和微服务节点的通信实际上都只是通过内存拷贝实现的。95图片来自：Pattern:ServiceMesh一、熟悉微服务架构的基本原理另一条路-ServiceMeshSidecar只负责网络通信。还需要有个组件来统一管理所有sidecar的配置。在ServiceMesh中，负责网络通信的部分叫数据平面（dataplane），负责配置管理的部分叫控制平面（controlplane）。数据平面和控制平面构成了ServiceMesh的基本架构。SeviceMesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。即使回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。96图片来自：Pattern:ServiceMesh一、熟悉微服务架构的基本原理结束、也是开始微服务不是架构演变的终点。往细走还有Serverless、FaaS等方向。另一方面也有人在唱合久必分分久必合，重新发现单体架构……不管怎样，微服务架构的改造暂时告一段落了。小明满足地摸了摸日益光滑的脑袋，打算这个周末休息一下约小红喝杯咖啡。97Q&ADocker容器项目实战第二章Docker基本管理任务2.1-1：理解Docker技术基本原理

任务导入和职业能力要求100PaaS云平台的搭建，要从容器化开始。最常用的容器技术是docker，首先要理解docker技术的基本原理任务导入职业能力要求掌握docker技术要点理解docker基本原理掌握docker基本架构一、掌握docker技术要点什么是dockerdocker是一个开源的应用容器引擎，基于go语言开发并遵循了apache2.0协议开源docker可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的linux服务器，以实现虚拟化容器使用沙箱机制，相互之间不会有接口，并且容器开销极其低101一、掌握docker技术要点容器和虚拟机容器直接在linux主机操作系统上运行，并与其他容器共享主机的内核，它运行的一个独立的进程，不占用其他任何可执行文件的内存，非常轻量虚拟机运行的是一个完成的操作系统，通过虚拟机管理程序对主机资源进行虚拟访问，相比之下需要的资源更多102一、掌握docker技术要点容器化的优势灵活：即使是最复杂的应用也可以集装箱化轻量级：容器利用并共享主机内核可互换：可以即时部署更新和升级便携式：可以在本地构建，部署到云，并在任何地方运行可扩展：可以增加并自动分发容器副本可堆叠：可以垂直和即时堆叠服务103一、掌握docker技术要点docker和Kubernetes的关系DockerConEU(2017)上，Solomon宣布Docker将原生支持Kubernetes，也就是说Kubernetes将和Swarm一样作为Docker平台的编排管理系统。这包括DockerEE、DockerCE以及DockerforMac/Windows等全平台的支持104二、理解docker基本原理docker的技术基础-LXCLXC为LinuxContainer的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其它复杂性提供了在单一可控主机节点上支持多个相互隔离的servercontainer同时执行的机制。LinuxContainer有点像chroot，提供了一个拥有自己进程和网络空间的虚拟环境，但又有别于虚拟机，因为LXC是一种操作系统层次上的资源虚拟化docker并不是LXC替代品，docker底层使用了LXC来实现，LXC将linux进程沙盒化，使得进程之间相互隔离，并且能够控制各进程的资源分配。在LXC的基础之上，docker提供了一系列更强大的功能105二、理解docker基本原理docker核心技术架构名称空间（Namespaces）控制组（cgroups）联合文件系统（UnionFS）容器格式106二、理解docker基本原理名称空间（Namespaces）docker本质就是宿主机的一个进程，通过namespaces实现资源隔离名字空间是Linux内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响107二、理解docker基本原理控制组（cgroups）控制组（cgroups）是Linux内核的一个特性，主要用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，才能避免当多个容器同时运行时的对系统资源的竞争cgroup的四大功能：资源限制：可对任务使用的资源总额进行限制优先级分配：通过分配的cpu时间片数量及磁盘IO带宽大小，相当于控制任务运行优先级资源统计：可以统计系统的资源使用量，如cpu时长，内存用量等任务控制：cgroup可对任务执行挂起、恢复等操作108二、理解docker基本原理联合文件系统（UnionFS）联合文件系统是一种分层、轻量级并且高性能的文件系统，支持对文件系统的修改作为一次提交来一层层的叠加109联合文件系统是Docker镜像的基础。镜像可通过分层来进行继承，基于基础镜像，可以制作各种具体的应用镜像。不同Docker容器可共享一些基础的文件系统层，同时再加上自己独有的改动层，大大提高了存储的效率Docker中使用的AUFS（AnotherUnionFS）就是一种联合文件系统。AUFS支持为每一个成员设定只读、读写和写出权限。对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)二、理解docker基本原理容器格式最初，Docker采用了LXC中的容器格式。自1.20版本开始，Docker也开始支持新的libcontainer格式，并作为默认选项对更多容器格式的支持，还在进一步的发展中110三、掌握docker基本架构docker三个重要概念image镜像docker镜像就是一个只读模板。如：一个镜像可包含一个完整的centos，仅安装apache或其他应用，镜像可用来创建docker容器，docker提供了一个简单机制来分层创建镜像或更新现有镜像，用户也可直接下载已做好的镜像使用111三、掌握docker基本架构docker三个重要概念container容器docker利用容器来运行应用，容器是从镜像创建的运行实例容器可被启动，开始、停止、删除、每个容器都是互相隔离、保证安全的平台，可以将容器看做简易版的linux环境（包括root用户权限、镜像空间、用户空间和网络空间等）和运行在其中的应用程序112三、掌握docker基本架构docker三个重要概念repository仓库仓库是集中存储镜像文件的场所，registry是仓库注册服务器，实际上每个注册服务器上都可存放多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）仓库分为公有仓库和私有仓库。最大的公有仓库是dockerHub113三、掌握docker基本架构docker逻辑架构dockerdaemon：docker守护进程，即server端。可以是远程或本地的，客户端Dockerclient通过restapi进行通信RESTAPI：实现了client和server间的交互协议dockerCLI：为用户提供统一的操作界面实现容器和镜像的管理，客户端提供只读镜像，通过镜像可创建多个容器，容器可以是RFS（Rootfilesystem根文件系统）或包含了用户应用的RFS114三、掌握docker基本架构docker物理架构Docker使用C/S架构Client通过接口与Server进程通信实现容器的构建，运行和发布client和server可以运行在同一个集群，也可以通过跨主机实现远程通信115Q&ADocker容器项目实战第二章Docker基本管理任务2.1-2：熟悉Docker使用的基本知识

任务导入和职业能力要求118PaaS云平台的搭建需要使用docker，首先要熟悉docker使用的基本知识任务导入职业能力要求熟悉Docker的版本情况熟悉DockerEngine的基本情况熟悉DockerHub的基本使用一、熟悉Docker的版本情况docker的版本演变2013年3月开始推出0.1.0版本，到2017年2月1.13的版本都采用x.x的形式为专注于Docker的商业业务，Docker公司将Docker项目改名为Moby，交由社区自行维护，将Docker本身拆分为Docker-CE免费版和Docker-EE商业版，由自己维护119版本名版本号说明Docker（docker.io，docker-engine）1.x.x以前的Docker开源版本，docker.io是由Ubuntu发布的deb包，docker-engine是Docker公司官方发布的deb包Moby

YY.MM更名后由社区维护的开源项目Docker-CEYY.MM，如19.06，代表19年6月由Docker公司维护的免费版本，CE分为Edge和Stable版本，Edge:

月版本，每月发布一次

Stable:季度版本，每季度最后一月发布一次Docker-EEYY.MMDocker商业版，只有Stable版本，每季度发布一次一、熟悉Docker的版本情况dockerCE与dockerEEDockerCommunityEdition（CE）社区版免费的Docker产品的新名称，DockerCE包含了完整的Docker平台，非常适合开发人员和运维团队构建容器APPEnterpriseEdition(EE)商业版由docker公司支持，可在经过认证的操作系统和云提供商中使用，并可运行来自DockerStore的经过认证的容器和插件。提供Basic、Standard、Advanced三个服务层次120一、熟悉Docker的版本情况Moby与DockerMoby提供许多类似乐高积木的标准组件，能够让用户使用提供的框架和工具组合成定制的容器系统