哈工大面向服务的软件系统 期末开卷提纲

引言

本课程期末考试为开卷，博主2022年期末卷面94/100，总分92.9排名第2/82，现分享复习提纲以供学弟学妹们参考。本提纲仅供参考，切勿进行其他目的的使用。

基于2021秋季考试题的思考

一、Spring Boot的优点是：

1. 非常快速的部署和开发；

2. 便捷的自动配置；

3. 无需XML配置，可以使用注释和Java代码；

4. 内置的安全性；

5. 内置Tomcat、Jetty和Undertow；

6. 支持多种类型的数据库和持久层框架；

7. 提供Model View Controller（MVC）架构和RESTful Web服务；

8. 具有优雅而强大的测试环境；

9. 提供了一整套完整的Spring生态系统；

10. 提供Spring Data，Spring Cloud和Spring Security项目。

Springboot的优点有：1.快速入门 2.零配置，遵循“约定大于配置” 3.集成了大量常用的第三方库的配置 4.内嵌容器 5.简化maven配置

Spring Boot的优点

从最根本上来讲，Spring Boot 就是一些库的集合，它能够被任意项目的构建系统所使用。它使用 “习惯优于配置” （项目中存在大量的配置，此外还内置一个习惯性的配置）的理念让你的项目快速运行起来。 Spring boot 其实不是什么新的框架，它默认配置了很多框架的使用方式，就像 maven 整合了所有的 jar 包，spring boot 整合了所有的框架，有以下几个特点：

（1）为所有 Spring 开发提供一个更快更广泛的入门体验。

（2）零配置。无冗余代码生成和XML 强制配置，遵循“约定大于配置” 。

（3）集成了大量常用的第三方库的配置， Spring Boot 应用为这些第三方库提供了几乎可以零配置的开箱即用的能力。

（4）提供一系列大型项目常用的非功能性特征，如嵌入式服务器、安全性、度量、运行状况检查、外部化配置等。

（5）Spring Boot 不是Spring 的替代者，Spring 框架是通过 IOC 机制来管理 Bean 的。Spring Boot 依赖 Spring 框架来管理对象的依赖。Spring Boot 并不是Spring 的精简版本，而是为使用 Spring 做好各种产品级准备。

二、持续集成：

持续集成（Continuous Integration，简称CI）是一种软件开发实践，它要求团队的成员经常将新的代码合并到共享仓库中，以便尽早地发现集成错误。CI 还要求在合并后立即运行测试，以检查是否存在集成错误，如果发现错误，则可能会拒绝将代码提交到主干上。

如何实践中实现持续集成：

开发实践中实现持续集成的一般步骤包括：编写代码、合并新的代码到共享版本控制仓库中、运行自动化测试套件并生成测试报告、部署可执行文件到指定服务器以及针对生产环境发布新的产品版本。

三、幂等性: 同样的方式做两次, 而最终结果不变, 相当于只做了一次的特性, 分布式服务系统中哪些服务需要满足幂等性?

幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的。幂等性是分布式系统设计中的一个重要概念，对超时处理、系统恢复等具有重要意义。声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试。例如，在因网络中断等原因导致请求方未能收到请求返回值的情况下，如果该资源具备幂等性，请求方只需要重新请求即可，而无需担心重复调用会产生错误。实际上，我们常用的HTTP协议的方法是具有幂等性语义要求的，比如：

get方法用于获取资源，不应有副作用，因此是幂等的；

post方法用于创建资源，每次请求都会产生新的资源，因此不具备幂等性；

put方法用于更新资源，是幂等的；

delete方法用于删除资源，也是幂等的。

四、什么是服务的灾难性雪崩, 如何解决灾难性雪崩?

定义：由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

原因：1.服务提供者不可用（硬件故障，程序bug，缓存击穿，用户泛洪式请求）2.重试加大流量，代码逻辑重试3.服务调用者不可用最后导致一个服务不可用，造成一系列服务的不可用，这样的后果往往是不可预料的。

解决方法：降级：超时降级、资源不足时降级，降级后可以配合降级接口返回托底数据。实现一个fallback方法，当请求后端服务出现异常的时候，可以使用fallback方法返回的值

隔离：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用

熔断：当失败率达到阀值自动触发降级，熔断器触发的快速失败会进行快速恢复

缓存：提供了请求缓存

请求合并：提供了请求合并

五、单体架构应用和微服务架构应用区别点 (可以从架构思想, 开发技术和部署技术等说明)

微服务架构是将应用程序表示为微小的、松散耦合的服务集合。由于整体的复杂性被转移到了服务的协调级别上，因此每个服务都代表了一种业务功能，可以更加容易地去定位相关代码。而单体架构是将几个离散的功能组成一个单元，作为一个整体进行测试、部署和扩展。由于所有组件都是相互依赖的，因此通常不能够单独运行。这就意味着某个模块中的错误，可能会减慢、甚至破坏整个应用程序。

微服务的优点：易于扩展、应用组件相互独立、有清晰的边界，并能通过HTTP实现通信、可以使用不同的编程语言和数据存储、开发过程可被分到多个团队、可被独立部署、易于更新和维护、使用较小的代码库

微服务的缺点：难以监控、具有更为复杂的服务部署、服务之间的通信需要额外安全加固、性能会有所降低、鉴于分布式系统的远程调用较慢，因此经常存在着编程难度大和失败的风险、增加了运营的复杂性

六、负载均衡的意义

负载均衡的意义是指将负载的任务进行平衡、分摊到多个操作单元上进行运行，主要是用来避免单一应用由于并发等原因，导致应用宕机从而让系统整体无法使用、多负载同时工作，则使用负载均衡能够解决高并发的问题并实现服务的高可用。

负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。

负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

1、软/硬件负载均衡

软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

2、本地/全局负载均衡

负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡针对本地范围的服务器群做负载均衡，全局负载均衡针对不同地理位置、不同网络结构的服务器群做负载均衡。

本地负载均衡不需要花费高额成本购置高性能服务器，只需利用现有设备资源,就可有效避免服务器单点故障造成数据流量的损失，通常用来解决数据流量过大、网络负荷过重的问题。同时它拥有形式多样的均衡策略把数据流量合理均衡的分配到各台服务器。如果需要在现在服务器上升级扩充，不需改变现有网络结构、停止现有服务，仅需要在服务群中简单地添加一台新服务器。

全局负载均衡主要解决全球用户只需一个域名或IP地址就能访问到离自己距离最近的服务器获得最快的访问速度，它在多区域都拥有自己的服务器站点，同时也适用于那些子公司站点分布广的大型公司通过企业内部网(Intranet)达到资源合理分配的需求。

全局负载均衡具备的特点：

1、提高服务器响应速度，解决网络拥塞问题，达到高质量的网络访问效果。

2、能够远距离为用户提供完全的透明服务,真正实现与地理位置无关性

3、能够避免各种单点失效，既包括数据中心、服务器等的单点失效，也包括专线故障引起的单点失效。

七、单体架构VS微服务

（一）优缺点分析

1.单体架构的优点

易于开发和部署

单体架构的应用程序一直存在。许多工具确实促进了简单的开发和部署策略。开发人员需要执行一块可部署的代码，而不是在单独的实体中进行更新。

高性能

单体应用相比于微服务有着更好的性能，这也是单体应用的关键优势。基于微服务的应用程序可能需要对 100 个其他微服务进行 100 次不同的 API 调用才能加载一个 UI 屏幕。而在单体应用中，一个 API 调用可以达到相同的目的，因为它具有集中的代码和内存。

2.单体架构的缺点

紧耦合

单体应用程序中的服务模块是紧耦合的。业务逻辑纠缠不清，很难隔离应用程序，因此可扩展性成为一个挑战。

缓慢的构建和发布周期

由于代码库非常庞大，这会延缓应用程序的开发和测试周期的速度。

3.微服务架构的优点

更好的组织

由于整个代码库被分解为更小的服务，组织起来相对单体架构更好。微服务有特定的工作，不依赖于其他组件。

敏捷性高

使用微服务，团队中的个人可以处理单个模块。每个人都可以独立构建模块和部署模块，从而减少团队的运维摩擦，提高软件交付的敏捷性。

（二）部署策略

单体应用遵循传统部署，由于单体应用具有三层架构，因此它们一直部署在 Apache Tomcat、Oracle Weblogic、IBM Websphere 等 Web 服务器上。

而微服务给系统架构师设计部署策略带来了困难，下面让我们关注微服务部署策略。

微服务以高可扩展性而闻名，因此，支持的 IT 基础设施也应该是可扩展的。以下是一些可根据用户的要求选择的部署策略：

一项服务-一位主机

这是部署应用程序的传统方法。多个服务可以部署在一个虚拟机上。配置了一台虚拟机并用于部署各种服务。这最终会降低基础架构的成本，因为所有服务都在一台主机上运行。 、

一服务-一容器

在这个模型中，运行在支持 Docker 和 Kubernetes 的生态系统上的应用程序起着至关重要的作用。这些服务被打包为镜像，并部署在虚拟主机上的容器中。容器非常轻巧且易于构建。容器化可以实现服务的完全隔离。微服务的容器化还优化了基础架构成本，因为多个服务托管在单个虚拟机上。

无服务器部署

使用 Node.js、Python 和 Java 等编程语言开发的应用程序可以支持无状态和无服务器部署。创建了一个 Lambda 函数，该函数运行微服务并处理所有请求。同样，此策略是最具成本效益的策略之一，因为组织仅按云环境中的请求数量计费。

（三）运营影响

在考虑任何基础设施时，我们想到的第一个问题是，“新技术的运营影响是什么？” 如果您决定采用微服务，那么毫无疑问，您应该考虑一些重大影响。

成本

有几个方面属于“成本”的范畴。入门成本、维护成本、开发成本、质量成本、速度和性能成本以及拥有成本。成本是在最终决定采用任何软件架构时考虑的一个重要因素。

可靠性

在可靠性方面，微服务也占上风。单体应用只不过是一大块应用程序二进制文件。无论如何，如果部署失败，整个应用程序就会崩溃。与单体相比，微服务非常可靠。即使在服务失败的情况下，应用程序也不会作为一个整体出现故障，而且还有多种服务检测工具。在高层次上，在微服务上运行的应用程序的可靠性更高。

可扩展性

单体可以通过多种方式进行缩放。其中之一是使用大量虚拟机，然后使用负载平衡器路由请求。微服务架构更加细粒度，因此每个微服务的扩展更加细粒度和灵活。可扩展性是任何企业应用程序的对比因素。因此，市场上有多种技术可以确保微服务在水平和垂直方向上都是可扩展的。市场上一些流行的工具是 Amazon EKS、Amazon ECS、Docker 和 Kubernetes。为了精确扩展和更好地利用资源，微服务显然是赢家。

开发时间

由于庞大的规模和更高的依赖性，单体架构中的构建和部署机制更加复杂和耗时。微服务对资源的敏感度较低，并且可以扩展。由于模块彼此解耦，因此更容易构建和部署。这增加了在微服务上运行的应用程序的敏捷性，并显着缩短了微服务应用程序进入市场的时间。

（四）如何从单体迁移到微服务

在从单体架构迁移到微服务之前，应该进行一些特定的应用程序级更改。下面我们将从宏观的角度讨论几种拥抱微服务的方法。

构建优化

单体 Java 项目是使用 ANT 和 Maven 构建的，第一步是简化构建，此外还应该删除影响构建的依赖项和其他外部因素。

解耦依赖

简化构建过程后，应该删除单体应用程序的模块化依赖项，可能必须重建代码以实现这种级别的解耦。

优化本地开发

构建、部署和测试应该在本地开发环境中以更快的速度进行。像 Docker 这样的工具也应该在本地被接受。这有助于加快诸如设置本地数据库等操作任务。

并行开发

应在专用于所有不同微服务的代码存储库中创建多个分支。这种设置将促进所有单体的并行开发，并提高软件开发生命周期 (SDLC) 的敏捷性。

采用基础架构即代码 (IaC)

采用 IaC 将使基础架构更加统一和一致。

章节重点总结

第二章 面向服务开发技术

1.MVC

优点：

耦合性低

视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动 MVC 的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

重用性高

一个模型能被多个视图共享，这意味着从模型传回来的数据能以多种方式显示，而不需要为每一种显示方式编写特定的代码，大大减少了代码量。

部署快

使用 MVC 模式使开发时间得到相当大的缩减，后台程序员集中精力于业务逻辑，前端程序员集中精力于表现形式上。

可维护性高

分离视图层和业务逻辑层也使得 WEB 应用更易于维护和修改。

有利软件工程化管理

由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。

缺点

增加系统结构和实现的复杂性

对于简单的界面，严格遵循 MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。所以说 MVC 不适合用于小型、中型应用程序。

视图与控制器间的过于紧密的连接

视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

Webservice

1.UDDI

UDDI是：

· 在线企业和服务注册的一个规范。

· 为使用W3C和IETF标准设计，如XML、HTTP、DNS和SOAP。

· 由UDDI社区管理。

· 免费(至少是这样)。

(1)UDDI数据模型。UDDI数据模型是一个用于描述商业组织和Web Service的XML Schema。

(2)UDDI API。UDDI API是一组用于查找或发布UDDI数据的方法，UDDI API基于SOAP。

(3)UDDI注册服务。UDDI注册服务数据是Web Service中的一种基础设施，UDDI注册服务对应着服务注册中心的角色。

特点

与平台无关、开放的体系结构和创新的自由、广泛支持。

2.axis

axis全称Apache Extensible Interaction System 即阿帕奇可扩展交互系统。Axis本质上就是一个SOAP引擎，提供创建服务器端、客户端和网关SOAP操作的基本框架。Axis版本是为Java编写的，不过为C++的版本正在开发中。但Axis并不完全是一个SOAP引擎，它还是一个独立的SOAP服务器和一个嵌入Servlet引擎（例如Tomcat）的服务器。

3.xfire

第三章SOA

1. SOA概述

SOA（Service-Oriented Architecture，面向服务的架构）是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。

一个典型的SOA结构如下图所示：

其中，对于其中的单个服务而言，其内部结构一般如下：

2. SOA设计原则：

SOA的设计原则包括：

明确的接口定义：接口需满足稳定、明确、封装性等要求。

自包含与模块化：实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

粗粒度：服务数量不应太多，依靠消息交互而不是远程过程调用。

松耦合：减少各个服务间的相互依赖和影响，各个服务的位置、实现技术、当前状态以及私有数据，对服务请求者不可见。

互操作性、兼容性和策略声明。

3. SOA实现方法

SOA作为一种架构设计的概念和思想，需要借助具体的技术和方法来实现。目前SOA的主流实现方法包括：Web Service、服务注册表和企业服务总线。

3.1 Web Service

3.2 服务注册表

服务注册表(Service registry)提供一个策略执行点，在这个点上，服务可以在SOA中注册，从而可以被发现和使用。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。

3.3 企业服务总线ESB

ESB(Enterprise Service Bus)将企业中各个不同的服务连接在一起。因为各个服务是异构的，没有统一的标准，各个异构系统对外提供的接口是各式各样的，SOA使用ESB来屏蔽异构系统对外提供的不同接口，以此来达到服务间高效的互联互通。

企业服务总线，即ESB全称为Enterprise Service Bus，指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

企业服务总线(EnterpriseServiceBus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能 。

4. SOA关键技术

与SOA紧密相关的技术主要有UDDI、WSDL、SOAP和REST等，这些技术都是以XML为基础发展而来的。

4.1 UDDI

UDDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便该服务被发现和使用，同时它也定义了一种编程接口。该技术规范主要包括数据模型、API和注册服务三部分。

4.2 WSDL

WSDL（Web Service Description Language，Web服务发现语言）是基于XML语法对服务进行描述的语言，包括服务实现定义和服务接口定义。服务实现定义描述服务提供者如何实现特定的服务接口，包含服务和端口描述。服务接口定义是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。

4.3 SOAP

SOAP（Simple Object Acess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范，该协议通过HTTP承载XML格式化的消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用(RPC）。SOAP主要包括封装、编码规则、RPC表示和绑定四个部分。

4.4 REST

REST（Representational State Transfer，表达性状态转移）是一种针对Web服务的设计和开发方式，通常使用HTTP、XML、URI和HTML等流行协议或标准，可以有效降低开发的复杂性，提高系统的可伸缩性。REST对信息的操作基本只支持POST、GET、PUT和DELETE，这些操作基于如下的设计理念：

网络上的所有事物都被抽象为资源；

每个资源对应一个唯一的资源标识；

通过通用的连接件接口对资源进行操作；

对资源的各种操作不会改变资源标识；

所有操作都是无状态的。

5. 为什么ESB是SOA的重要架构部分, 而Dubbo却不使用ESB技术

ESB（Enterprise service bus）-----企业服务总线的简写。

就是企业数据总线的意思，他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换。（格式转换、协议转换、代理、编排、安全控制、监控、不支持高并发，类似于路由器维护着一张路由表进行路由转发）。它是实现soa架构风格中的一个重要组成单元。

把ESB从webservice的角度去理解，webservice是使用SOAP、XML、UUID、WSDL相结合的方式来解决不同应用间通信的，属于一种系统与系统直接的直接关联，而ESB则可以看作一个中转站，用于接收上一层发送的信息，然后处理并转发到下一层。而这样做的好处是： 若多个系统间通讯时，使用传统的webservice，将可能会出现如下情况。而是用ESB的方式，则会更加的清晰：并且，由于两个系统之间不需要直接进行交互，也避免了因为两个系统之间的接口不一致而需要在两个系统之中进行协调的尴尬，在ESB中A系统传输的内容可以和B系统所接收的内容形式上不一致，但可以通过ESB中间的逻辑进行修改赋值，这样一来两个系统只需要关注自身的业务和暴露的接口就可以了，而不用去考虑接收信息或发送信息的系统。

代表性的项目有：JBOSS ESB,Mule,Camel 以及一些其他的esb项目

什么是服务注册，dubbo又是什么

就是将所有的服务接口（很多时候是hession协议的接口）,注册到一个中心的分布式服务集群上（你可以考虑成apache的zookeeper服务实现的效果）。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用。（注册目录服务、监控、负载均衡、安全控制、分布式强健壮、适用于高并发）

代表性开源项目有：阿里的dubbo，淘宝的HSF(现在不知道是否继续开源了)

dubbo最初是阿里的一个Java远程调用框架（阿里贡献出来给开源社区了，现在是apache dubbo），不是什么“注册服务管理”，dubbo支持使用zookeeper或者redis做注册中心，所以你也可以认为dubbo包含了注册服务管理的功能（主要强调注册、管理功能较弱）、但又不仅仅是服务注册管理。

特点：

1、ESB的特点

ESB一般采用集中式转发请求，适合大量异构系统集成，并且压力不大的情况，但集中式转发也是有优势的，比如调用方用http协议，提供方用rmi协议，转发就可以转换协议，对双方都透明。另外，在总线上还可以执行流程引擎，做服务编排，比如A和B两个服务经常一起调，就可以编排成服务C，而不用再单独启一个服务去做。还有，安全，流控，做起来也更方便。

支持groovy类型的脚本语言，在总线上可以给数据格式做转换

2、服务注册管理 及dubbo的特点

采用的是分布式调用，注册中心只记录地址信息，然后直连调用，适合并发及压力比较大的情况。

对于网站应用，大多是垂直业务，直接从数据库拉数据展示。

dubbo不是ESB那种试图管天管地啥都要管的东西，dubbo的目的很明确，就是提供一个java应用之间的、高效的远程调用框架。

dubbo的注册中心，只是提供一个注册和查找服务的地方，查找到之后，A系统就直接调用B系统的服务了，中间并没有一个统一的数据通道之类的东西。

至于什么java应用和.net应用之间怎么交互，XML转换为Json、或者Json转XML，dubbo说：我从来就没想过这些啊！

3、应用场景

1、ESB

esb最常见的场景是，把系统里的集成逻辑，单拉出来， 放到esb容器里来部署，并跟应用系统适配。 这样让应用系统变得只有自己的业务逻辑，简单、轻薄。

劣势：在所有的服务上增加了一个总线作为沟通的渠道。对于较大的并发量会将瓶颈推到ESB总线上。很多时候ESB总线都采用MQ类的消息服务器来异步处理缓解压力

2、服务注册

淘宝和阿里的各个业务系统提供了很多的接口，这个时候需要统一管理提供个各子业务系统使用，让各个子业务系统可以通过注册中心很快找到对应的服务

劣势：服务编排和协议转换还是靠各个业务子系统了

4、综述

1、两类开源项目侧重点不同，ESB侧重任务的编排，性能问题可通过异构的方式来进行规避。无法支持特别大的并发。同一个网段的模式下，总线模式（ESB）相比P2P模式的要差。但是总线模式相比P2P模式，他即是服务注册和发现机制。又是服务提供者。所以，在跨网段服务访问上，Dubbo这种注册模式是不能互通的。但是ESB是可以的（部署在两个网络的边界上），作为两边服务的Exchanger/网关机制，这是ESB模式不能被替换的优点

2、服务注册侧重服务的治理，将各个服务颗粒化，各个子业务系统在程序逻辑上完成业务的编排。但是比较实用较大的并发量，因为dubbo类的只是存放服务地址。有zookeeper类的分布式通讯框架，能保证单点的失败不影响整个系统的业务调用，因为业务接口都是在各个提供服务的子系统中。

6.SOA和微服务

应用ESB，这里就有个极为明显的特征，那就是服务是比较粗粒度的，可以是一个系统，系统内部多么复杂那是系统内部的事情，对外部，大家都暴露统一的接口协作方式，而且系统之间明显涉及到跨部门协作，系统也是由不同厂商的产品实现。

微服务之间明显的特征就是相互协作密集，而且不存在跨部门，或不同厂商互相合作的复杂问题，那么这种情况下，微服务几乎都可以是同平台同构系统下，小型团队密切协作，从而达到高效率迭代开发和服务快速上线发布。

因此微服务不需要接入复杂的ESB，而降低了开发效率和部署实施效率，运行过程也会降低微服务远程快速调用接口完成请求协作的优势。微服务面对外部异构系统集成，只需要通过简单的消息中心，就能实现平台消息与外界系统的统一集成，例如直接将整个互联网医疗平台集成进医疗信息系统的ESB当中，与医院其他系统进行数据协同，这时候ESB在院内与互联网之间的协作就很有效果了。

1.ESB的服务之间都通过ESB总线互相访问,微服务中内部服务之间可以直接访问,外部服务通过网关接入

2.ESB的总线的功能拆开来就相当于微服务中以下几个独立的微服务

服务目录 == 服务发现：都是解决服务注册和寻址问题

路由/协议转换/聚合 == 网关：区别是ESB中外部访问和内部服务之间访问都需要路由

消息传递 == 消息总线：区别是ESB同时提供异步和同步消息

验证和授权 == 独立的微服务: 区别是对微服务来讲这视为一个业务功能

3. ESB总线是集中化的,而微服务的细颗粒度使得横向扩容非常容易

4. ESB对服务进行统一管理,而微服务的复杂网络需要配合服务网格来管理

并不是说微服务就不需要ESB，只是传统的ESB是单体架构的，较笨重，微服务属于轻量级的，像RestCloud ESB平台由API网关和ESB服务编排平台组成，API网关负责API的路由和透传，ESB总线平台则负责以API为中心链接各个业务系统进行数据的推送、拉取、事务控制、异常数据告警等能力。相比传统的ESB而言，微服务架构中的更轻量，更灵活。

5.ESB与BEPL的对比

确定要使用的运行时

如前所述，Process Server和ESB之间存在一些功能重叠。 两者都可以使用适配器。 两者都可以转换数据。 两者都可以支持复合服务模式。 在决定针对特定业务问题使用最佳软件时，您需要决定使用哪种软件。作为架构师，您需要对两个软件平台的功能都有很好的了解。 收集了完整的要求集之后，就可以开始进行决策了。

首先要看的是需求，然后确定其中一个选项是否更合适。 例如，如果需要有状态过程，则可以立即排除ESB。 另一方面，如果要求在0.2秒内处理消息转换，则显然选择ESB。 ，并非现实世界中的所有项目都是如此干and。 通常，您需要检查几个条件才能确定最佳选择。

ESB的优势

ESB的主要优势之一是处理消息。 消息输入，消息输出，可能应用了协议或格式中介。 当需求明确要求进行消息处理时，ESB将具有多个优势，包括能够处理转换中更大的复杂性。 如果需求需要基本的ESB功能之一，例如消息路由，转换或协议中介，那么ESB将是不二之选。

ESB的另一个优势是性能。 ESB被设计为能够处理大量消息。 例如，如果要求说每天将有200,000条消息，那么ESB显然是更好的选择。

如果要求是以数据为中心的，那么ESB是不二之选。

BPEL的优势

BPEL引擎的主要优势是能够协调业务流程。 如果需求要求使用复杂逻辑的流程，则BPEL将是一个更好的选择。 WS-BPEL具有容器活动，例如，ESB不支持的while循环和作用域。 ESB中的逻辑通常很简单，而WS-BPEL可以处理更复杂的情况。

WS-BPEL引擎（例如WebSphere Process Server）的另一个优势是能够拥有长期运行的业务流程并保持状态。 当需要状态时，您不应使用ESB，因为维护状态需要大量自定义代码。 如果要求进行状态处理，则可以排除ESB作为选择。如果需求以流程为中心，那么WS-BPEL是不二之选。

6.SOA与微服务架构之间的主要区别是什么？

SOA(Service Oriented Architecture)面向服务的架构：他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

微服务架构：其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构=80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

7.Mock 与 Stub 有什么区别？

Mock：关注行为验证。细粒度的测试，即代码的逻辑，多数情况下用于单元测试。

Stub：关注状态验证。粗粒度的测试，在某个依赖系统不存在或者还没实现或者难以测试的情况下使用，例如访问文件系统，数据库连接，远程协议等。

8.Web技术的发展

Web 1.0

Web 1.0是指万维网发展的第一阶段。早些时候，Web 1.0中只有少数内容创建者，其中绝大多数用户是内容的消费者。个人网页很常见，主要由ISP运行的Web服务器上托管的静态页面或免费的Web托管服务组成。

在Web 1.0 中，在网站上上网时的广告是被禁止的。此外，在Web 1.0中，ofoto是一个在线数码摄影网站，用户可以在上面存储，共享，查看和打印数码图片。Web 1.0 是一个内容交付网络 （CDN），它支持在网站上展示信息。它可以用作个人网站。它根据查看的页面向用户收取费用。它具有使用户能够检索特定信息的目录。Web 1.0的时代大致从1991年到2004年。

Web 1.0 网站的四个设计要点包括：

1.静态页面。

2.内容从服务器的文件系统提供。

3.使用服务器端包含或通用网关接口 （CGI） 构建的页面。

4.框架和表格用于定位和对齐页面上的元素。

Web 2.0

2004年，当“Web 2.0”这个词因蒂姆·奥莱利和戴尔·多尔蒂举办的第一届Web 2.0会议（后来称为Web 2.0峰会）而出名时，这个词是由达西·迪努奇在1999年创造的。Web 2.0 是指为最终用户突出显示用户生成的内容、可用性和互操作性的全球网站。Web 2.0也被称为参与式社交网络。它不是指对任何技术规范的修改，而是修改网页的设计和使用方式。这种转变是有益的，但当变化发生时，似乎不是这样。Web 2.0允许在社交媒体对话中相互交互和协作，作为虚拟社区中用户生成内容的创建者。Web 2.0 是 Web 1.0 的增强版本。

网络浏览器技术用于 Web 2.0 开发，它包括 AJAX 和 JavaScript 框架。最近，AJAX 和 JavaScript 框架已成为创建 Web 2.0 站点的一种非常流行的方法。

Web 2.0 的五个主要功能：

1.信息的自由排序，允许用户对信息进行集体检索和分类。

2.响应用户输入的动态内容。

3.使用评估和在线评论在网站所有者和网站用户之间流动信息。

4.开发了允许自行使用的 API，例如通过软件应用程序。

5.Web访问导致的关注点不同，从传统的互联网用户群到更广泛的用户。

Web 2.0 的用处

社交网络包含几个在线工具和平台，人们可以在其中分享他们的观点，意见，想法和经验。Web 2.0 应用程序倾向于与最终用户进行更多的交互。因此，最终用户不仅是应用程序的用户，也是下面提到的这 8 个工具的参与者：

1.播客2.博客3.标记4.使用 RSS 进行策划5.社交书签6.社交网络7.社会化媒体8.网页内容投票

Web 3.0

它指的是网络利用率和交互的演变，包括将Web更改为数据库，集成DLT（分布式账本技术区块链就是一个例子），并且数据可以帮助根据个人的需求制作智能合约。它实现了Web后端的升级，经过长时间专注于前端（Web 2.0主要关于AJAX，标记和其他前端用户体验创新）。Web 3.0是一个术语，用于描述Web使用和多个路径之间的交互的许多演变。在这种情况下，数据不是私有的，而是共享的，其中服务为相同的Web/相同的数据显示不同的视图。

语义Web（3.0）承诺以比谷歌现有的引擎模式更合理的方式建立“世界的信息”。从机器概念的角度来看，这尤其正确，而不是人类的理解。语义Web需要使用像OWL这样的声明性本体论语言来产生特定于领域的本体，机器可以使用这些本体来推理信息并得出新的结论，而不仅仅是匹配关键字。

可以帮助我们定义Web 3.0的主要功能：

1.语义Web

Web 的后续演变涉及语义网。语义网改进了网络技术的需求，通过基于理解单词含义的能力（而不是关键字或数字）的搜索和分析来创建，共享和连接内容。

2.人工智能

将此功能与自然语言处理相结合，在Web 3.0中，计算机可以像人类一样区分信息，以提供更快，更相关的结果。它们变得更加智能，以满足用户的要求。

3.3D图形

三维设计在Web 3.0的网站和服务中被广泛使用。博物馆指南，电脑游戏，电子商务，地理空间环境等都是使用3D图形的示例。

4.连接性

通过Web 3.0，由于语义元数据，信息的联系更加紧密。因此，用户体验演变为利用所有可用信息的另一个连接级别。

5.无处不在

内容可由多个应用程序访问，每个设备都连接到Web，并且服务可以在任何地方使用。

6.DLT和智能合约

在DLT的帮助下，我们可以有一个几乎不可能破解的数据库，人们可以从中获得他们的内容和他们可以拥有的东西的价值。这是一种技术，它通过集成智能合同，使一个不受信任的社会成为可能，而不需要中间人作为担保人，以使合同在特定的原因下发生。它基于DLT的数据。这是一个强大的工具，可以让世界变得更美好，并为互联网上的每个人创造更多的机会。

9.

第四章：微服务

1.SpringCloud与Dubbo的区别

两者都是现在主流的微服务框架，但却存在不少差异：

初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理

生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。

调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。

组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

相同点：SpringCloud 和Dubbo可以实现RPC远程调用框架，可以实现服务治理。

不同点：SpringCloud是一套目前比较网站微服务框架了，整合了分布式常用解决方案遇到了问题注册中心Eureka、负载均衡器Ribbon ，客户端调用工具Rest和Feign，分布式配置中心Config，服务保护Hystrix，网关Zuul Gateway ，服务链路Zipkin，消息总线Bus等。

优点: 把客户端和服务端解耦，更松耦合 提高可用性，因为消息中间件缓存了消息，直到消费者可以消费，支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点：消息中间件有额外的复杂性

dubbo内部实现功能没有SpringCloud强大（全家桶），只是实现服务治理，缺少分布式配置中心、网关、链路、总线等，如果需要用到这些组件，需要整合其他框架。

相关资料：

SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。

Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

请谈谈对SpringBoot 和SpringCloud的理解

SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务

SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系.

2.dubbo和Feign远程调用的差异

Feign是SpringCloud中的远程调用方式，基于成熟Http协议，所有接口都采用Rest风格。因此接口规范更统一，而且只要符合规范，实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。

Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。

不过这种性能差异除非是达极高的并发量级，否则无需过多考虑。

3.Eureka和Zookeeper注册中心的区别

SpringCloud和Dubbo都支持多种注册中心，不过目前主流来看SpringCloud用Eureka较多，Dubbo则以Zookeeper为主。两者存在较大的差异：

从集群设计来看：Eureka集群各节点平等，没有主从关系，因此可能出现数据不一致情况；ZK为了满足一致性，必须包含主从关系，一主多从。集群无主时，不对外提供服务

CAP原则来看：Eureka满足AP原则，为了保证整个服务可用性，牺牲了集群数据的一致性；而Zookeeper满足CP原则，为了保证各节点数据一致性，牺牲了整个服务的可用性。

服务拉取方式来看：Eureka采用的是服务主动拉取策略，消费者按照固定频率（默认30秒）去Eureka拉取服务并缓存在本地；ZK中的消费者首次启动到ZK订阅自己需要的服务信息，并缓存在本地。然后监听服务列表变化，以后服务变更ZK会推送给消费者。

4.SpringCloud中的常用组件有哪些？

Spring Cloud的子项目很多，比较常见的都是Netflix开源的组件：

Spring Cloud Config

集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置的刷新及加密、解密操作。

Spring Cloud Netflix

Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。

Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；

Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；

Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；

Feign：基于Ribbon和Hystrix的声明式服务调用组件；

Zuul：API网关组件，对请求提供路由及过滤功能。

Spring Cloud Bus

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。

Spring Cloud Consul

基于Hashicorp Consul的服务治理组件。

Spring Cloud Security

安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。

Spring Cloud Sleuth

Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。

Spring Cloud Stream

轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。

Spring Cloud Task

用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。

Spring Cloud Zookeeper

基于Apache Zookeeper的服务治理组件。

Spring Cloud Gateway

API网关组件，对请求提供路由及过滤功能。

Spring Cloud OpenFeign

基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。

5.微服务调用关系复杂，如何做监控和错误排查？

企业中对于微服务监控有一套东西，叫做APM。比如：SpringCloudSeluth+Zipkin，Pinpoint、Skywalking，可以实现性能监控、链路跟踪（精确到某个代码，某条sql）、CPU运行情况，链路运行耗时。当然， 还可以借助于分布式日志管理系统。把项目运行的日志收集，形成统计报表，放入elasticsearch，便于搜索查看。比如：ELK技术栈、GrayLog

6.Hystix的作用是什么？

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。比较常用的手段就是线程隔离和服务熔断。

7.Spring cloud 和 Dubbo 各自的优缺点是什么?

简而言之，Dubbo确实类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户，然而鉴于Dubbo的社区现状（曾经长期停止维护，2017年7月31日团队又宣布重点维护），使用起来还是有一定的门槛。Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表已被数据库失效时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。

虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。所以，对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适。同时，对于人手不足的初创产品而言，这么重的架构维护起来也不是很方便。

Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。

但它并没有重复造轮子，而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架（我们需要特别感谢Netflix ，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，Spring Cloud主要是对Netflix开源组件的进一步封装），通过Spring Boot 进行封装集成并简化其使用方式。基于Spring Boot，意味着其使用方式如Spring Boot 简单易用；能够与Spring Framework、Spring Boot、Spring Data 等其他Spring 项目完美融合，意味着能从Spring获得巨大的便利，意味着能减少已有项目的迁移成本。

当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等，鉴于Dubbo完备的功能和文档且在国内被众多大型互联网公司选用，考拉自然也选择了Dubbo作为服务化的基础框架。其实相比于Dubbo，Spring Cloud可以说是一个更完备的微服务解决方案，它从功能性上是Dubbo的一个超集，个人认为从选型上对于一些中小型企业Spring Cloud可能是一个更好的选择。提起Spring Cloud，一些开发的第一印象是http+JSON的rest通信，性能上难堪重用，其实这也是一种误读。微服务选型要评估以下几点：内部是否存在异构系统集成的问题；备选框架功能特性是否满足需求；http协议的通信对于应用的负载量会否真正成为瓶颈点（Spring Cloud也并不是和http+JSON强制绑定的，如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案）；社区活跃度、团队技术储备等。作为已经没有团队持续维护的开源项目，选择Dubbo框架内部就必须要组建一个维护团队，先不论你要准备要集成多少功能做多少改造，作为一个支撑所有工程正常运转的基础组件，问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。

鉴于服务发现对服务化架构的重要性，再补充一点：Dubbo 实践通常以ZooKeeper 为注册中心（Dubbo 原生支持的Redis 方案需要服务器时间同步，且性能消耗过大）。针对分布式领域著名的CAP理论（C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性），Zookeeper 保证的是CP ，但对于服务发现而言，可用性比数据一致性更加重要 ，而 Eureka 设计则遵循AP原则 。

8.SpringCloud的优缺点分析

优点：

服务拆分粒度更细，有利于资源重复利用，有利于提高开发效率

可以更精准的制定优化服务方案，提高系统的可维护性

微服务架构采用去中心化思想，服务之间采用Restful等轻量级通讯，比ESB更轻量

适于互联网时代，产品迭代周期更短

缺点：

微服务过多，治理成本高，不利于维护系统

分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

优点：

1）服务的独立部署

每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。

2）服务的快速启动

拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。

3）更加适合敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。

4）职责专一，由专门的团队负责专门的服务

业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。

5）服务可以动态按需扩容

当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

6）代码的复用

每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

缺点：

1）分布式部署，调用的复杂性高

单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。

2）独立的数据库，分布式事务的挑战

每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，

比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性，后面的章节会给大家做具体介绍。

3）测试的难度提升

服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。

4）运维难度的提升

在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。

9.分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。

服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的 100% 可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪；在分布式系统中，由于网络原因或自身的原因，服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪；

10.四种客户端弹性模式

客户端负载均衡模式（client load balance）：让客户端从服务注册中心查找服务的所有实例，然后缓存服务实例的物理位置；

断路器模式（circuit breaker）：远程服务调用时间太长，断路器将会介入并中断调用 ；

后备模式（fallback）：远程服务调用失败时，服务消费者将执行替代代码路径， 并尝试通过其他方式执行操作，而不是生成一个异常；

舱壁模式（bulkhead）：每个远程资源、都是隔离的，并分配给线程池；

11.服务容灾的几种解决方案

服务隔离：即舱壁模式。将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。常见的隔离方式有：线程池隔离和信号量隔离；

服务超时：在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放线程；

服务降级：即后备模式。服务提供一个托底方案，一旦服务无法正常调用，就使用托底方案；

服务熔断：即断路器。上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。一种“牺牲局部，保全整体”的策略；

服务限流：限制系统的输入和输出流量已达到保护系统的目的；

12.服务降级的参考指标

服务降级需要有一个参考指标，一般来说有以下几种常见方案；

平均响应时间：比如15内持续进入5个请求，对应时刻的平均响应时间均超过阈值，那么接下来在一个固定的时间窗口内，对这个方法的访问都会自动熔断；

异常比例：当某个方法每秒调用所获得的异常总数的比例超过设定的阈值时，该资源会自动进入降级状态，也就是在接下来的一个固定时间窗口中，对这个方法的调用都会自动返回；

异常数量：和异常比例类似，当某个方法在指定时间窗口内获得的异常数量超过闽值时会触发熔断；

13.服务限流的作用

限流的主要目的是通过限制并发访问数或者限制一个时间窗口内允许处理的请求数量来保护系统，一旦达到限制数量则对当前请求进行处理采取对应的拒绝策略，比如跳转到错误页面拒绝请求、进入排队系统、降级等；

从本质上来说，限流的主要作用是损失一部分用户的可用性，为大部分用户提供稳定可靠的服务；

实际开发中的限流应用：

在 Nginx 层添加限流模块限制平均访问速度；

通过设置数据库连接池、线程池的大小来限制总的并发数；

通过 Guava 提供的 Ratelimiter 限制接口的访问速度；

TCP 通信协议中的流量整形；

14.对于分布式系统服务依赖的保护的解决方案

1、熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

2、隔离模式：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。

3、限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

15.服务熔断与服务降级

服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回”错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

Hystrix服务降级：其实就是线程池中单个线程障处理，防止单个线程请求时间太长，导致资源长期被占有而得不到释放，从而导致线程池被快速占用完，导致服务崩溃。整体资源快不够用了，忍痛将某些服务先关掉，待度过难关，再回来开启。

所谓降级，就是一般是从整体符合考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。请求超时降级，线程资源不足降级，降级之后可以返回自定义数据。

16.分布式配置中心的作用

分布式配置中心能干嘛？

集中管理配置文件

不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release

运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置将配置信息以REST接口的形式暴露

第五章——微服务架构

1.持续集成与持续交付

测试基础设施是指支持自动化测试运行、测试开发、测试管理以及与研发环境集成的综合性平台。敏捷测试离不开稳定、高效、准确的基础设施，以满足对于持续测试、持续反馈的需要；同时，持续集成、持续交付和 DevOps 环境必须实现和测试基础设施的无缝集成，才能够满足软件在各种环境中持续验证的需要。

“持续集成”（Continuous Integration，CI）在 1996 年就被列入了极限编程的核心实践，到 2006 年 Martin Fowler 提出了比较完善的方法与实践。持续集成是一个软件开发实践，在开发过程中团队成员频繁地提交代码到集成环境，每次集成都通过自动化的构建和测试尽可能快地发现问题，让软件始终保持在一个可工作的状态。这里的可工作应该理解为软件可安装、可运行，基本功能可用，可以进一步开展测试。

“持续交付”（Continuous Delivery，CD）是对持续集成的延伸，更是敏捷宣言“拥抱变化胜于遵循计划”价值观的体现。CD 是指软件经过开发环境、测试环境、准生产环境里的持续验证，满足了客户需求和质量目标，成为可交付给客户的产品。持续交付也是研发团队以一种可持续的方式把软件产品交付给客户的能力。持续交付的下一步就是持续部署，通过自动化的方式实现软件在生产环境中的部署。

https://blog.csdn.net/rdhj5566/article/details/122558414

2.如何具体实现持续集成

https://blog.csdn.net/sinat_39598192/article/details/123615681

https://www.cnblogs.com/vali/p/14604455.html

3.如何具体实现持续交付

https://cloud.tencent.com/developer/article/2143853

持续集成是持续交付和持续部署的基础。持续集成使得整个开发团队保持一致，消除了集成所引起的问题的延期。虽然持续集成使得代码可以快速合并到主干中，但此时软件仍然是未在生成环境中进行实际使用过的。软件的功能是否正常，功能是否符合用户的需求，这在持续集成阶段仍然是未知的。只有将软件部署到了生成环境，交付给用户使用之后，才能检验出软件真正的价值。而持续交付与持续部署的实践，正是从持续集成到“最后一公里”的保障。

所谓交付，就是将最终的产品发布到线上环境，提供给用户使用。对于一个微服务架构系统来说，将一个应用拆分成多个独立的服务，每个服务都具有业务属性，并且能独立地被开发、测试、构建、部署。换言之，每个服务都是一个可交付的产品。那么在这种细粒度的情况下，如何有效保障每个服务的交付效率，快速实现其业务价值，是摆在微服务面前的一个难题。

而持续交付是一系列的开发实践方法，用来确保代码能够快速、安全地部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮，就能将应用安全地部署到生产环境中。

而持续部署是持续交付的更高一级的阶段。即当所有代码所有的改动都通过了自动化测试之后，都能够自动地部署到生产环境里。持续发布与持续部署一个重要的差别在于，持续发布需要人工来将应用部署到生成环境中（即部署前，应用需要人工来校验一遍），而持续部署则是所有的流程都是自动化的，包括部署到生产环境的流程。图11-1很好地描述了持续发布与持续部署之间的差异。

持续交付与持续部署的意义

总的来说，持续交付与持续部署在敏捷开发过程中，实现速度、效率、质量的软件开发实践，可以持续为用户交付可用的软件产品。其中包括:

频繁的交付周期带来了更迅速的对软件的反馈。

可以迅速对产品进行改进，更好地适应用户的需求和市场的变化。

需求分析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，减少了浪费。

有力形成了“需求→开发→集成→测试→部署”的可持续的反馈闭环。

什么是持续交付流水线

在持续交付中，持续集成服务器将把开发到部署过程中的各个环节衔接起来，组成一个自动化的持续交付流水线，作为整个交付过程的协调中枢。依靠持续集成服务器，对软件的修改能够快速地、自动化地经过测试和验证，最后部署到生产环境中去。在自动化测试和环境都具备的情况下，集成服务器可以减少开发人员大部分的手工工作。流水线应向团队提供反馈，对每个人所参与的错误操作进行提示。

典型的持续交付流水线中，大致会经历构建自动化和持续集成、测试自动化和部署自动化等阶段。

1.自动化构建和持续集成

开发人员将实现的新功能集成到中央代码库中，并以此为基础进行持续的构建和单元测试。这是最直接的反馈循环，持续交付流水线会通知开发团队他们的应用程序代码的健康情况。

2.自动化测试

在这个阶段，新版本的应用程序将经过严格测试，以确保它满足所有期望的系统质量。这包括软件的所有相关方面，包括功能、安全性、性能等，这些都会由流水线来进行验证。该阶段可以涉及不同类型的自动或手动活动。

3.自动化部署

每次将应用程序安装在测试环境前都需要重新部署，但自动化部署最为关键的是自动化部署的时机。由于前面的阶段已经验证了系统的整体质量，这是一个低风险的步骤。部署可以分阶段进行，新版本最初可以先发布到生产环境的子集中，并在进行完整测试之后，推广到所有生产环境中。这极大降低了新版本发布的风险。部署是自动的，这样只需要花费几分钟就能向用户提供可靠的新功能。

持续交付流水线的最佳实践

下面总结了在构建持续交付流水线时一些好的实践经验。

1.做好配置管理

持续交付流水线需要有平台配置和系统配置的支持，这样就能允许团队自动或手动按下按钮来创建、维护和拆除一个完整的环境。

自动平台配置可确保您的候选应用程序能够部署到正确配置的且可重现的环境中去，然后进行测试。它还促进了横向扩展性，并允许企业在沙箱环境中随时尝试新产品。

2.合理编排流水线

持续交付流水线中的多个阶段涉及不同的人员团队协作，并且所有人员都需要监测新版本的应用程序的发布。持续交付流水线的编排提供了整个流水线的顶层视图，允许您自行定义和控制每个阶段的具体动作，这样就能细化整个软件交付过程。

3.不要添加新的功能，直到通过质量测试

持续交付使您的组织能够一个接一个地快速可靠地将新功能带入生产环境中。这意味着每个单独的功能需要在展开之前进行测试，确保该功能满足整个系统的质量要求。

在传统开发环境中，开发团队通常试图一次性实现一个完整的新版本，仅在项目接近完成时来解决软件质量属性（如鲁棒性、可扩展性、可维护性等）。然而，随着最终工期的临近，以及迫于预算的压力，质量往往会首先被舍弃。

可以通过在获得质量权之前不添加新功能的原则来避免不良的系统质量。在实践中，您应该始终首先满足并保持质量水平，然后才考虑逐步向系统添加功能。使用持续交付，每个新功能都需要从一开始就满足整个系统所期望的质量水平。只有在达到此质量水平后，才能将该功能移至生产环境。

配置管理

1.什么是配置管理

配置管理是指一个过程，通过该过程，将所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索。这里的项目相关的产物可以是源代码、需求文档、设计文档、测试文档等，也包括了项目配置、库文件、发布包、编译工具等。

配置管理是软件开发过程中极其重要的一部分，持续集成、部署流水线、自动化测试等若想真正发挥好作用，都必须做好配置管理工作。

2.如何进行配置管理

《持续交付》一书对配置管理做了重要的论述，并通过版本控制、依赖管理、软件配置管理和环境管理四部分来分别分析了配置管理的重要性。以下是所总结的配置管理的实践经验。

版本控制:在版本控制方面，我们提倡将所有东西都提交到版本控制库中，包括操作系统的配置信息。使用版本控制库的好处是显而易见，你可以放心地变更或删除任何文件，版本控制库可以帮你来回溯历史。常用的版本控制库有很多，包括Bazaar、Mercurial、Git、SVN等。这里的建议是，除非是历史原因导致变更版本控制库软件比较困难，否则，采用Git等分布式版本控制库软件可以极大提高团队协作的效率。对于提交变更而言，一个好的实践是频繁提交变更到主干，因为当你汇聚的更改越多，变更间隔的时间越长，合并到主干时发现的问题就会越多。频繁提交代码，就是一个频繁集成代码的过程。

依赖管理:对于一个颇具规模的软件而言，很难不依赖第三方的软件或第三方的库文件的实现。当项目中依赖变多时，依赖关系将变得错综复杂，特别是某些软件存在兼容性方面的问题，各个版本之间的接口还不能通用，这样，通过手工等方式进行依赖的管理将变得极其困难。在实际开发中，我们倾向于使用依赖管理工具来帮助解决这些依赖管理，对于Java开发者而言，Maven或 Gradle是个不错的选择。建议在本地保存一份外部库的副本，这样可以加快开发的启动速度。另外，将依赖库的版本在团队中进行统一，可以有效防止不同版本之间出现的奇怪问题。

软件配置管理:几乎所有的软件都有配置文件，这使得软件可以在不做修改的前提下，仅需要调整配置文件的内容，就实现软件的差异化。不同的软件部署到不同的生产环境中，其所使用的配置文件也是不同的。将软件配置进行统一管理，这样在软件升级时，仍然能够恢复用户最初的软件设置。一个好的事件是把配置信息当成源代码看待，并对它进行测试。

环境配置管理:没有哪个应用程序是孤岛。每个应用程序都依赖于硬件、软件、基本设施及外部系统才能正常工作。所以在提倡自动化方式管理环境时，还需要考虑环境配置信息，例如:

*应用程序所采用的各种操作系统或中间件，包括其版本、补丁级别及配置设置;

*应用程序所依赖的需要安装到环境中的软件包，以及这些软件包的具体版本和配置;

*应用程序正常工作所必需的网络拓扑结构;

*应用程序所依赖的所有外部服务，以及这些服务的版本和配置信息。

持续交付与DevOps

对于交付成功的软件来说，开发和运维是两个必不可少的过程。在传统的组织架构中，开发团队和运维团队往往是分属于不同的部门，各自部门的职责可能会引人相互抵触的目标:对于开发人员来说，开发人员的职责是负责交付新特性及对变更承担责任;而运维人员则试图保持所有功能能够平稳运行，对他们来说，避免变更正是降低运行风险的一种最有力的手段。在这种互相冲突的目标面前，最终导致产品不能得到很好的更新，也就无法持续给用户创造价值。

DevOps 正是为了打破开发团队与运维团队之间的壁垒而进行的一次尝试。DevOps是Develop-ment与Operations的缩写，DevOps推动了一套用于思考沟通和协作的过程和方法，用于促进开发、技术运营和质保部门之间的沟通、协作与整合,其推崇的团队将会是一个结合开发、质量保证( QA)、IT运营等整个职责的跨职能团队，如图11-2所示。这也正是Amazon所提倡的“You Build It，YouRun It（谁开发，谁运维）”的开发模式。

持续交付和 DevOps在其意义上及目标上是相似的（旨在快速交付产品），但它们是两个不同的概念。

DevOps有更广泛的范围，围绕:组织变革，具体来说，支持参与软件交付的各类人员之间的更大的协作，包括开发、运营、质保、管理等;自动化软件交付过程。

持续交付是一种自动化交付软件的方法，并且侧重于:结合不同的过程，包括开发、集成、测试、部署等;更快，更频繁地执行上述过程。

DevOps和持续交付有共同的最终目标，它们经常被联合使用，并且在敏捷方法和精益思想中有着共同的远景:小而快的变化，以最终客户的价值为重点。它们在内部进行良好的沟通和协作，从而实现快速交付产品，降低风险。

在微服务架构系统的开发中，我们倾向于采用DevOps的方式来组建全能型的团队。

4.kvm和docker之间有什么区别?

Docker简介

Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。 Docker 的基础是 Linux 容器（LXC）等技术。在 LXC 的基础上 Docker 进行了进一步的封装，让用户不需要去关心容器的管理，使得操作更为简便。用户操作 Docker 的容器就像操作一个快速轻量级的虚拟机一样简单。下面的图片比较了 Docker 和传统虚拟化方式的不同之处，可见容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。

Docker与KVM（传统虚拟机）对比

作为一种新兴的虚拟化方式，Docker 跟传统的虚拟化方式相比具有众多的优势。

1、Docker容器的启动可以在秒级实现，这相比传统的虚拟机方式要快得多。 其次，Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。

2、容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行 10 个不同的应用就要起 10 个虚拟机，而Docker 只需要启动 10 个隔离的应用即可。

3、 虚拟化技术依赖物理CPU和内存，是硬件级别的；而docker构建在操作系统上，利用操作系统的containerization技术，所以docker甚至可以在虚拟机上运行。

4、虚拟化系统一般都是指操作系统镜像，比较复杂，称为“系统”；而docker开源而且轻量，称为“容器”，单个容器适合部署少量应用，比如部署一个redis、一个memcached。

5、传统的虚拟化技术使用快照来保存状态；而docker在保存状态上不仅更为轻便和低成本，而且引入了类似源代码管理机制，将容器的快照历史版本一一记录，切换成本很低。

6、传统的虚拟化技术在构建系统的时候较为复杂，需要大量的人力；而docker可以通过Dockfile来构建整个容器，重启和构建速度很快。更重要的是Dockfile可以手动编写，这样应用程序开发人员可以通过发布Dockfile来指导系统环境和依赖，这样对于持续交付十分有利。

7、当然KVM对比于容器也有一个比较大的优势就是可以使用不同的操作系统或内核。所以，举例说，你可以使用微软Azure，同时运行Windows Server2012的实例和SUSE Linux企业级服务器的实例。至于Docker，所有容器都必须使用同样的操作系统和内核。

5.K8S不用docker的原因

1、docker比k8s发布的早；

2、Docker 本身不兼容 CRI 接口，官方并没有实现 CRI 的打算，同时也不支持容器的一些新需求，社区想要摆脱Dockershim的高维护成本，。

3、k8s不能直接与docker通信，只能与 CRI 运行时通信，要与 Docker 通信，就必须使用桥接服务(dockershim)，k8s要与docker通信是通过节点代理Kubelet的Dockershim（k8s社区维护的）将请求转发给管理容器的 Docker 服务。

4、Dockershim 一直都是 Kubernetes 为了兼容 Docker 获得市场采取的临时方案（决定）。

5、k8s在过去因为 Docker 的热门而选择它，现在又因为高昂的维护成本而放弃它，我们能够从这个过程中体会到容器领域的发展和进步。

6、对于已经统治市场的k8s来说，Docker 的支持显得非常鸡肋，移除代码也就顺理成章。

7、在集群中运行的容器运行时往往不需要docker这么复杂的功能，k8s需要的只是 CRI 中定义的那些接口。

6.未来Docker会完全替代kvm之类虚拟化吗？还是说两者可以共存？

近期，两者会并存，未来存在容器被取代的可能。并存：虚拟化能提供更多可能，跨操作系统，甚至是异构平台模拟，都是仍然有业务需要，而容器无法提供的。而目前容器的主流应用在于其高性能和基础的隔离，以及功能灵活。取代：容器至今仍有安全问题无法解决，对操作系统的要求也导致各种障碍。在实现其关键特性前提下，目前的容器技术本身有可能被其它技术替代。

从技术发展方向上长期来讲是替代,但是实际是会共存很久,因为有十分漫长的道路要走.os层技术不是孤立市场独自存在的,容器的用武前提是全面的应用微服务化.从目前实际来看,软件项目初期就直接以微服务化的方式设计的项目大多结局很糟糕.单体设计在软件项目初期仍然是主流形态,协作容易,迭代快; 在项目中后期遇到性能瓶颈时候再转用微服务架构当前来看是比较好的选择.微服务化在国内已经喊了5~6年了,然而架构与标准发展依然没有野火燎原.大家对技术变革的热情应该已经淡化了,该转的应该也已经转了.容器架构本身是好技术,但是在小型项目中由于架构原因目前基本没什么用武之地, 而小型项目占软件项目80%以上.所以理论上是可以替代,但实际是共存,就好像有了IPv6并没有淘汰IPv4一样.

两则各有优劣，互补，所以长时间来说会共存。

虚拟机原理：运行模式是基于宿主机内核驱动形式，加上一层硬件虚拟化技术（Hypervisor），然后在之上再堆砌一层完整的客户系统（Guest OS）。

优势：完整的系统内核，隔离程度会更高，在VPS场景下还是最佳的选择。

劣势：因为是Guest OS是一个完整的系统，有开机引导、启动过程，所以它会慢很多；（这点是相对Docker技术来说的）消耗更多的硬件资源（CPU，内存，磁盘等）。

Docker原理：（对Windows不熟，这里基于Linux来说）用cgroup实现资源的隔离，namespace实现系统环境的隔离。再搞一套运行环境封装规则——镜像，Dockerfile，就很容易的实现了运行环境的隔离。

优势：系统结构非常简单，较比虚拟机少了（Hypervisor和Guest OS层），所以它的启动速度——秒开；一切操作都是一个容器内运行时环境，相当于直接基于宿主机内核，所以对硬件的消耗，较比虚拟机而言——少太多了；前面两个优点，促使它能胜任许多现代系统设计、运维、更新概念，比如：DevOps，微服务，更加简单的方便的持续集成等等。

劣势：资源限制（CPU，内存，磁盘等）粒度做不到虚拟机那么高。

扯点其他的很明显可以看出，虚拟机和Docker优劣互补，所以结论就是，至少未来5年，他们俩还是共存的。Docker更轻量，所以可以用它干好多事情，事情多了就需要有一个掌舵人——kubernetes，做容器资源调度，让“单机版”的容器，协同，高效运行。

7.Jenkins

(一)主要用途

1.持续、自动地构建/测试软件项目。

2.监控一些定时执行的任务。

(二)Jenkins主要特性

1.易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。

2.易于配置-所有配置都是通过其提供的web界面实现。

3.集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。

4.生成JUnit/TestNG测试报告。

5.分布式构建支持Jenkins能够让多台计算机一起构建/测试。

6.文件识别：Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。

7.插件支持：支持扩展插件，你可以开发适合自己团队使用的工具。

8.敏捷开发和瀑布模型

8.1瀑布模型

核心思想

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型有以下优点

（1）为项目提供了按阶段划分的检查点。

（2）当前一阶段完成后，您只需要去关注后续阶段。

（3）可在迭代模型中应用瀑布模型。

增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

（4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型有以下缺点

（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

（4）瀑布模型的突出缺点是不适应用户需求的变化。

8.2敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏

捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发的优势：

1.短期目标明确

开发的最终意义就是为了完成目标，而如果一个目标过于长远，那么就容易造成短期的盲目乐观，认为工期还早，从而造成短期的任务完成不及时，从而最终导致接近项目交付时工作量暴增，甚至出现延期交付的情况。

有短期的目标，开发目标明确，知道什么节点该做什么。每一期的任务目标会不断的鞭策开发，督促开发及时完成任务。如果某个节点造成耗时过多，也可以及时暴露出来，及时解决。

2.按照优先级去完成任务，优先做高优先级的。

有时候会遇到这样的一种场景，产品提了一堆需求，我们依照顺序去做。但是有些价值不高的需求因为先提出来，导致开发会优先去做。快速迭代的过程中，这种低优先级的需求很有可能会出现刚开发到一半就被告知不需要做了的场景。敏捷开发可以很好的避免这种问题。

3.拆分大需求，方便开发。

敏捷开发需要开发去评估工作难度，分别为1，2，3，5，8，13。如果一个需求超过13，那么必须拆分为若干个小的需求去做。就好比吃一只全羊时有可能无从下手，但是拆分成多个部分时，吃起来则舒畅多了。

4.避免无用开发。

相对于瀑布流开发的一个人完整的跟一个需求，敏捷开发要求每个需求必须在开发前时明确的。

传统瀑布流的话，哪怕需求不明确，仍然可以继续开发，当做到不明确的点的时候，再去和产品确认。而这时候如果发现所做的并不是产品想要的，那么之前所做的工作就白费了。

敏捷开发的话，做需求前必须先明确需求要做什么，计划会上先介绍规划，这样就等于和产品再过了一遍需求，确认做出来的就是产品想要的。

5.这是一个自组织的。砍掉了技术经理任务安排这个环节，自然效率会高。同时也锻炼了成员的沟通能力。

敏捷开发的劣势：

1.需要开发熟悉各个模块的逻辑，难度较高，同时，这也对代码规范清晰度提出了要求。

2.需要开发backup其它平台的开发，需要开发人员对全栈开发有一定的掌握。

3.需要较好的团队协作。

4.澄清会和计划会需要开发测试全部到场，会议时间有时候会持续很长。但是某些需求大多数人实际上并不参与，造成工时上的浪费。

5.一般来说，技术经理不会参与到所有组的敏捷开发中，所以比较难对某个成员的贡献作出客观的评价。