网站建设辶金手指谷哥十四,google推广方式和手段有哪些,wordpress get请求,公司自建网站需要多少钱引言本课程期末考试为开卷#xff0c;博主2022年期末卷面94/100#xff0c;总分92.9排名第2/82#xff0c;现分享复习提纲以供学弟学妹们参考。本提纲仅供参考#xff0c;切勿进行其他目的的使用。基于2021秋季考试题的思考一、Spring Boot的优点是#xff1a;1. 非常快速…引言本课程期末考试为开卷博主2022年期末卷面94/100总分92.9排名第2/82现分享复习提纲以供学弟学妹们参考。本提纲仅供参考切勿进行其他目的的使用。基于2021秋季考试题的思考一、Spring Boot的优点是1. 非常快速的部署和开发2. 便捷的自动配置3. 无需XML配置可以使用注释和Java代码4. 内置的安全性5. 内置Tomcat、Jetty和Undertow6. 支持多种类型的数据库和持久层框架7. 提供Model View ControllerMVC架构和RESTful Web服务8. 具有优雅而强大的测试环境9. 提供了一整套完整的Spring生态系统10. 提供Spring DataSpring 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提供一系列大型项目常用的非功能性特征如嵌入式服务器、安全性、度量、运行状况检查、外部化配置等。5Spring 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 BalanceCheckPoint 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 不适合用于小型、中型应用程序。视图与控制器间的过于紧密的连接视图与控制器是相互分离但却是联系紧密的部件视图没有控制器的存在其应用是很有限的反之亦然这样就妨碍了他们的独立重用。视图对模型数据的低效率访问依据模型操作接口的不同视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。Webservice1.UDDIUDDI是· 在线企业和服务注册的一个规范。· 为使用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.axisaxis全称Apache Extensible Interaction System 即阿帕奇可扩展交互系统。Axis本质上就是一个SOAP引擎提供创建服务器端、客户端和网关SOAP操作的基本框架。Axis版本是为Java编写的不过为C的版本正在开发中。但Axis并不完全是一个SOAP引擎它还是一个独立的SOAP服务器和一个嵌入Servlet引擎例如Tomcat的服务器。3.xfire第三章SOA1. SOA概述SOAService-Oriented Architecture面向服务的架构是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中所有的功能都被定义成了独立的服务所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统当然由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)因此其本身也会引入更多的复杂性。一个典型的SOA结构如下图所示其中对于其中的单个服务而言其内部结构一般如下2. SOA设计原则 SOA的设计原则包括 明确的接口定义接口需满足稳定、明确、封装性等要求。 自包含与模块化实现服务的功能实体是完全独立自主的独立进行部署、版本控制、自我管理和恢复。 粗粒度服务数量不应太多依靠消息交互而不是远程过程调用。 松耦合减少各个服务间的相互依赖和影响各个服务的位置、实现技术、当前状态以及私有数据对服务请求者不可见。 互操作性、兼容性和策略声明。3. SOA实现方法SOA作为一种架构设计的概念和思想需要借助具体的技术和方法来实现。目前SOA的主流实现方法包括Web Service、服务注册表和企业服务总线。3.1 Web Service3.2 服务注册表服务注册表(Service registry)提供一个策略执行点在这个点上服务可以在SOA中注册从而可以被发现和使用。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。3.3 企业服务总线ESBESB(Enterprise Service Bus)将企业中各个不同的服务连接在一起。因为各个服务是异构的没有统一的标准各个异构系统对外提供的接口是各式各样的SOA使用ESB来屏蔽异构系统对外提供的不同接口以此来达到服务间高效的互联互通。企业服务总线即ESB全称为Enterprise Service Bus指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢是构筑企业神经系统的必要元素。企业服务总线(EnterpriseServiceBusESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分是由中间件技术实现并支持SOA的一组基础架构功能 。4. SOA关键技术与SOA紧密相关的技术主要有UDDI、WSDL、SOAP和REST等这些技术都是以XML为基础发展而来的。4.1 UDDI UDDIUniversal Description Discovery and Integration统一描述、发现和集成提供了一种服务发布、查找和定位的方法是服务的信息注册规范以便该服务被发现和使用同时它也定义了一种编程接口。该技术规范主要包括数据模型、API和注册服务三部分。4.2 WSDLWSDLWeb Service Description LanguageWeb服务发现语言是基于XML语法对服务进行描述的语言包括服务实现定义和服务接口定义。服务实现定义描述服务提供者如何实现特定的服务接口包含服务和端口描述。服务接口定义是一种抽象的、可重用的定义行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型服务实现者可以根据这些标准定义来实现具体的服务。4.3 SOAPSOAPSimple Object Acess Protocol简单对象访问协议定义了服务请求者和服务提供者之间的消息传输规范该协议通过HTTP承载XML格式化的消息。通过SOAP应用程序可以在网络中进行数据交换和远程过程调用(RPC。SOAP主要包括封装、编码规则、RPC表示和绑定四个部分。4.4 RESTRESTRepresentational State Transfer表达性状态转移是一种针对Web服务的设计和开发方式通常使用HTTP、XML、URI和HTML等流行协议或标准可以有效降低开发的复杂性提高系统的可伸缩性。REST对信息的操作基本只支持POST、GET、PUT和DELETE这些操作基于如下的设计理念 网络上的所有事物都被抽象为资源 每个资源对应一个唯一的资源标识 通过通用的连接件接口对资源进行操作 对资源的各种操作不会改变资源标识 所有操作都是无状态的。5. 为什么ESB是SOA的重要架构部分, 而Dubbo却不使用ESB技术ESBEnterprise 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转XMLdubbo说我从来就没想过这些啊3、应用场景1、ESBesb最常见的场景是把系统里的集成逻辑单拉出来 放到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.0Web 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.02004年当“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/相同的数据显示不同的视图。语义Web3.0承诺以比谷歌现有的引擎模式更合理的方式建立“世界的信息”。从机器概念的角度来看这尤其正确而不是人类的理解。语义Web需要使用像OWL这样的声明性本体论语言来产生特定于领域的本体机器可以使用这些本体来推理信息并得出新的结论而不仅仅是匹配关键字。可以帮助我们定义Web 3.0的主要功能1.语义WebWeb 的后续演变涉及语义网。语义网改进了网络技术的需求通过基于理解单词含义的能力而不是关键字或数字的搜索和分析来创建共享和连接内容。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用的是ZookeeperSpringCloud生态丰富功能完善更像是品牌机Dubbo则相对灵活可定制性强更像是组装机。相同点SpringCloud 和Dubbo可以实现RPC远程调用框架可以实现服务治理。不同点SpringCloud是一套目前比较网站微服务框架了整合了分布式常用解决方案遇到了问题注册中心Eureka、负载均衡器Ribbon 客户端调用工具Rest和Feign分布式配置中心Config服务保护Hystrix网关Zuul Gateway 服务链路Zipkin消息总线Bus等。优点: 把客户端和服务端解耦更松耦合 提高可用性因为消息中间件缓存了消息直到消费者可以消费支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应缺点消息中间件有额外的复杂性dubbo内部实现功能没有SpringCloud强大全家桶只是实现服务治理缺少分布式配置中心、网关、链路、总线等如果需要用到这些组件需要整合其他框架。相关资料SpringCloudSpring公司开源的微服务框架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 NetflixNetflix OSS 开源组件集成包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。Eureka服务治理组件包括服务端的注册中心和客户端的服务发现机制Ribbon负载均衡的服务调用组件具有多种负载均衡调用策略Hystrix服务容错组件实现了断路器模式为依赖服务的出错和延迟提供了容错能力Feign基于Ribbon和Hystrix的声明式服务调用组件ZuulAPI网关组件对请求提供路由及过滤功能。Spring Cloud Bus用于传播集群状态变化的消息总线使用轻量级消息代理链接分布式系统中的节点可以用来动态刷新集群中的服务配置。Spring Cloud Consul基于Hashicorp Consul的服务治理组件。Spring Cloud Security安全工具包对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。Spring Cloud SleuthSpring Cloud应用程序的分布式请求链路跟踪支持使用Zipkin、HTrace和基于日志例如ELK的跟踪。Spring Cloud Stream轻量级事件驱动微服务框架可以使用简单的声明式模型来发送及接收消息主要实现为Apache Kafka及RabbitMQ。Spring Cloud Task用于快速构建短暂、有限数据处理任务的微服务框架用于向应用中添加功能性和非功能性的特性。Spring Cloud Zookeeper基于Apache Zookeeper的服务治理组件。Spring Cloud GatewayAPI网关组件对请求提供路由及过滤功能。Spring Cloud OpenFeign基于Ribbon和Hystrix的声明式服务调用组件可以动态创建基于Spring MVC注解的接口实现用于服务调用在Spring Cloud 2.0中已经取代Feign成为了一等公民。5.微服务调用关系复杂如何做监控和错误排查企业中对于微服务监控有一套东西叫做APM。比如SpringCloudSeluthZipkinPinpoint、Skywalking可以实现性能监控、链路跟踪精确到某个代码某条sql、CPU运行情况链路运行耗时。当然 还可以借助于分布式日志管理系统。把项目运行的日志收集形成统计报表放入elasticsearch便于搜索查看。比如ELK技术栈、GrayLog6.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作为服务化的基础框架。其实相比于DubboSpring Cloud可以说是一个更完备的微服务解决方案它从功能性上是Dubbo的一个超集个人认为从选型上对于一些中小型企业Spring Cloud可能是一个更好的选择。提起Spring Cloud一些开发的第一印象是httpJSON的rest通信性能上难堪重用其实这也是一种误读。微服务选型要评估以下几点内部是否存在异构系统集成的问题备选框架功能特性是否满足需求http协议的通信对于应用的负载量会否真正成为瓶颈点Spring Cloud也并不是和httpJSON强制绑定的如有必要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 IntegrationCI在 1996 年就被列入了极限编程的核心实践到 2006 年 Martin Fowler 提出了比较完善的方法与实践。持续集成是一个软件开发实践在开发过程中团队成员频繁地提交代码到集成环境每次集成都通过自动化的构建和测试尽可能快地发现问题让软件始终保持在一个可工作的状态。这里的可工作应该理解为软件可安装、可运行基本功能可用可以进一步开展测试。“持续交付”Continuous DeliveryCD是对持续集成的延伸更是敏捷宣言“拥抱变化胜于遵循计划”价值观的体现。CD 是指软件经过开发环境、测试环境、准生产环境里的持续验证满足了客户需求和质量目标成为可交付给客户的产品。持续交付也是研发团队以一种可持续的方式把软件产品交付给客户的能力。持续交付的下一步就是持续部署通过自动化的方式实现软件在生产环境中的部署。https://blog.csdn.net/rdhj5566/article/details/1225584142.如何具体实现持续集成https://blog.csdn.net/sinat_39598192/article/details/123615681https://www.cnblogs.com/vali/p/14604455.html3.如何具体实现持续交付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 ItYouRun 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的Dockershimk8s社区维护的将请求转发给管理容器的 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.拆分大需求方便开发。敏捷开发需要开发去评估工作难度分别为1235813。如果一个需求超过13那么必须拆分为若干个小的需求去做。就好比吃一只全羊时有可能无从下手但是拆分成多个部分时吃起来则舒畅多了。4.避免无用开发。相对于瀑布流开发的一个人完整的跟一个需求敏捷开发要求每个需求必须在开发前时明确的。传统瀑布流的话哪怕需求不明确仍然可以继续开发当做到不明确的点的时候再去和产品确认。而这时候如果发现所做的并不是产品想要的那么之前所做的工作就白费了。敏捷开发的话做需求前必须先明确需求要做什么计划会上先介绍规划这样就等于和产品再过了一遍需求确认做出来的就是产品想要的。5.这是一个自组织的。砍掉了技术经理任务安排这个环节自然效率会高。同时也锻炼了成员的沟通能力。敏捷开发的劣势1.需要开发熟悉各个模块的逻辑难度较高同时这也对代码规范清晰度提出了要求。2.需要开发backup其它平台的开发需要开发人员对全栈开发有一定的掌握。3.需要较好的团队协作。4.澄清会和计划会需要开发测试全部到场会议时间有时候会持续很长。但是某些需求大多数人实际上并不参与造成工时上的浪费。5.一般来说技术经理不会参与到所有组的敏捷开发中所以比较难对某个成员的贡献作出客观的评价。
文章转载自： http://www.morning.mjbkp.cn.gov.cn.mjbkp.cn http://www.morning.ypktc.cn.gov.cn.ypktc.cn http://www.morning.ybnps.cn.gov.cn.ybnps.cn http://www.morning.cjsnj.cn.gov.cn.cjsnj.cn http://www.morning.rhzzf.cn.gov.cn.rhzzf.cn http://www.morning.gtjkh.cn.gov.cn.gtjkh.cn http://www.morning.ntcmrn.cn.gov.cn.ntcmrn.cn http://www.morning.hbdqf.cn.gov.cn.hbdqf.cn http://www.morning.bqppr.cn.gov.cn.bqppr.cn http://www.morning.rldph.cn.gov.cn.rldph.cn http://www.morning.ymwnc.cn.gov.cn.ymwnc.cn http://www.morning.tqxtx.cn.gov.cn.tqxtx.cn http://www.morning.mjtft.cn.gov.cn.mjtft.cn http://www.morning.rjxwq.cn.gov.cn.rjxwq.cn http://www.morning.ckzjl.cn.gov.cn.ckzjl.cn http://www.morning.mtgnd.cn.gov.cn.mtgnd.cn http://www.morning.pgxjl.cn.gov.cn.pgxjl.cn http://www.morning.hxbps.cn.gov.cn.hxbps.cn http://www.morning.hlmkx.cn.gov.cn.hlmkx.cn http://www.morning.gtcym.cn.gov.cn.gtcym.cn http://www.morning.ruyuaixuexi.com.gov.cn.ruyuaixuexi.com http://www.morning.qfmcm.cn.gov.cn.qfmcm.cn http://www.morning.jqhrk.cn.gov.cn.jqhrk.cn http://www.morning.mpscg.cn.gov.cn.mpscg.cn http://www.morning.pdwny.cn.gov.cn.pdwny.cn http://www.morning.rzrbw.cn.gov.cn.rzrbw.cn http://www.morning.mjwnc.cn.gov.cn.mjwnc.cn http://www.morning.qrksj.cn.gov.cn.qrksj.cn http://www.morning.lhqw.cn.gov.cn.lhqw.cn http://www.morning.wdprz.cn.gov.cn.wdprz.cn http://www.morning.bkylg.cn.gov.cn.bkylg.cn http://www.morning.lbywt.cn.gov.cn.lbywt.cn http://www.morning.bwdnx.cn.gov.cn.bwdnx.cn http://www.morning.xsfny.cn.gov.cn.xsfny.cn http://www.morning.qpntn.cn.gov.cn.qpntn.cn http://www.morning.grlth.cn.gov.cn.grlth.cn http://www.morning.lxmks.cn.gov.cn.lxmks.cn http://www.morning.chmkt.cn.gov.cn.chmkt.cn http://www.morning.wypyl.cn.gov.cn.wypyl.cn http://www.morning.qgjxy.cn.gov.cn.qgjxy.cn http://www.morning.xnnxp.cn.gov.cn.xnnxp.cn http://www.morning.psxfg.cn.gov.cn.psxfg.cn http://www.morning.mlzyx.cn.gov.cn.mlzyx.cn http://www.morning.mrlls.cn.gov.cn.mrlls.cn http://www.morning.hgfxg.cn.gov.cn.hgfxg.cn http://www.morning.xyyplp.cn.gov.cn.xyyplp.cn http://www.morning.kryr.cn.gov.cn.kryr.cn http://www.morning.bdqpl.cn.gov.cn.bdqpl.cn http://www.morning.xfxnq.cn.gov.cn.xfxnq.cn http://www.morning.wgtr.cn.gov.cn.wgtr.cn http://www.morning.nlnmy.cn.gov.cn.nlnmy.cn http://www.morning.bhznl.cn.gov.cn.bhznl.cn http://www.morning.cdygl.com.gov.cn.cdygl.com http://www.morning.bxbnf.cn.gov.cn.bxbnf.cn http://www.morning.fkrzx.cn.gov.cn.fkrzx.cn http://www.morning.hymmq.cn.gov.cn.hymmq.cn http://www.morning.wljzr.cn.gov.cn.wljzr.cn http://www.morning.ytmx.cn.gov.cn.ytmx.cn http://www.morning.skscy.cn.gov.cn.skscy.cn http://www.morning.kyzxh.cn.gov.cn.kyzxh.cn http://www.morning.jydky.cn.gov.cn.jydky.cn http://www.morning.xhhqd.cn.gov.cn.xhhqd.cn http://www.morning.kpbn.cn.gov.cn.kpbn.cn http://www.morning.hlxxl.cn.gov.cn.hlxxl.cn http://www.morning.xhlpn.cn.gov.cn.xhlpn.cn http://www.morning.ywpwq.cn.gov.cn.ywpwq.cn http://www.morning.fwblh.cn.gov.cn.fwblh.cn http://www.morning.hbpjb.cn.gov.cn.hbpjb.cn http://www.morning.zshuhd015.cn.gov.cn.zshuhd015.cn http://www.morning.nj-ruike.cn.gov.cn.nj-ruike.cn http://www.morning.sphft.cn.gov.cn.sphft.cn http://www.morning.hxmqb.cn.gov.cn.hxmqb.cn http://www.morning.wxrbl.cn.gov.cn.wxrbl.cn http://www.morning.wrlxt.cn.gov.cn.wrlxt.cn http://www.morning.rwmq.cn.gov.cn.rwmq.cn http://www.morning.yodajy.cn.gov.cn.yodajy.cn http://www.morning.8yitong.com.gov.cn.8yitong.com http://www.morning.jcbmm.cn.gov.cn.jcbmm.cn http://www.morning.djlxz.cn.gov.cn.djlxz.cn http://www.morning.xbrxk.cn.gov.cn.xbrxk.cn
