在引入微服务时，您必须首先了解哪些微服务是什么，顾名思义，微服务必须从两个方面理解，什么是“微型”和什么是“服务” .2披萨团队。最初是由亚马逊首席执行官贝佐斯（Bezos）提出的，这意味着单个服务的设计。足以需要2个披萨）。因此，SO -CALLED服务必须区分系统并提供相对较小且独立的功能单元，即用户可以感知最小函数集。
Micro -Service首先是由Martin Fowler和James Lewis在2014年提出的。微型服务架构风格是开发单个应用程序来开发单个应用程序的一种方式。每个服务都在自己的过程中运行，并使用轻型维度机械通信通常为HTTP API。这些服务基于业务能力，可以通过自动部署机制独立部署。这些服务使用不同的编程语言和不同的数据存储技术，并保持最低的集中管理。
在传统的IT行业软件中，其中大多数都被各种独立系统堆叠在一起。这些系统的摘要是可伸缩性差，可靠性低和维护成本高。SOA服务是稍后引入的，但是由于SOA在早期使用了公交模式，因此此巴士模式与某些技术堆栈有很强的绑定，例如J2EE。这使许多企业很难离开系统。切换时间太长，成本太高，新系统的稳定性的收敛性也需要一段时间。最终，SOA看起来很漂亮，但是它变成了企业级别的豪华，并且中等程度和中等程度 -大小的公司令人生畏。
在相对较小的情况下，单个体系结构工作很好，但是随着系统大小的扩展，它会越来越多，主要是以下几点：
例如，某些项目中有数十万行代码。每个模块之间的差异越模糊，逻辑越混乱，代码越多，复杂性就越高，解决遇到的问题就越困难。
公司的员工流程正常。在离开之前，一些员工被忽略了代码质量的质量，从而导致许多停留的位置。由于单个项目代码的惊人数量，很难找到剩下的坑。这给新员工带来了极大的麻烦。员工流动越大，剩下的矿坑越多，越越来越被称为技术债务。
这是很好的理解。有许多单个体系结构模块，代码的数量非常大，导致部署项目的时间越来越多。开始一些项目需要一到二十分钟。这是一件可怕的事情？项目启动后的第二天，它通过了，开发人员的开发非常小。
例如，先前的项目是用struts2编写的。由于每个模块都有数千个连接，因此代码很大，逻辑还不够清晰。如果您想使用Spring MVC重建此项目，这将非常困难，付款，您可以付款。支付付款。费用将非常大，因此公司经常必须继续使用旧的支柱体系结构，这阻碍了技术创新。
例如，电影模块是一个CPU密集型模块，订单模块是IO密集模块。如果我们想提高订单模块的性能，例如增加内存和增加硬盘，但是由于所有模块都在体系结构下，因此因此它在体系结构下。因此，当我们扩大订单模块的性能时，我们必须考虑其他模块的因素，因为由于模块扩展的性能，我们不能损害其他模块的性能，而该模块的扩展无法按需扩展。
单个体系结构中的所有模块都与一块，代码很大，并且很难维护。微服务的每个模块都等同于一个单独的项目。代码量大大减少。解决问题相对容易。
单个体系结构中的所有模块共享一个数据库。存储方法相对单一。每个微服务模块都可以使用不同的存储方法（例如一些redis，有些使用mySQL等）。该数据库也是与其自己的数据库相对应的单个模块。
就像单个体系结构中所有模块使用的技术一样，每个微服务模块都可以使用不同的开发技术，并且开发模型更加灵活。
从基本意义上讲，微服务仍然是SOA架构。但是，含义是不同的。微服务不绑定某些特殊技术。在微服务系统中，可以有Java或Python.Systematic撰写的服务。因此，微服务本身与特定技术和强大的可扩展性无关。
微服务，关键不仅是微服务本身，而且是提供基本体系结构的系统。该体系结构允许微服务独立部署，运行和升级。该结构在服务之间“松散耦合”，并且该函数表现为一个统一的整体。此统一的“统一整体”显示了统一的样式接口，统一权威管理，统一的安全策略，统一的在线流程，统一日志和审计方法，统一的调度方法，统一的访问入口等。
微服务的目的是有效分开应用程序以实现敏捷开发和部署。
由微服务提倡的概念应该是间隔的，而不是集成的。以下是定义系统的系统的边界和接口。在一个团队中，团队完全堆叠以允许团队捕食，彼此的依赖关系可以减弱，并且可以降低跨系统的沟通成本。
微服务可以根据业务功能本身的独立性进行分割。如果系统提供的系统非常低，例如：操作系统内核，存储系统，网络系统，数据库系统等。它们之间有着密切的合作关系。如果被迫分裂成较小的服务单元，它将急剧增加集成的工作量，并且这种人工削减不能带来真正的业务隔离，因此它不能独立部署和不适合进行微服务。
您是否可以进行微服务取决于四个元素：
连续遇到从单个结构到微服务体系结构的服务边界划分的问题：例如，我们有用户服务来提供用户的基本信息，然后将用户的头像和图片分为新服务，好还是我应该合并到用户服务中？如果粒径太厚，它将返回单体的旧道路；如果太详细了，服务室的开销将不会被忽略，管理困难将提高索引级别。那么，到目前为止，没有标准可以称为服务边界划分，只能是根据不同的业务系统进行调整。
分裂的最大原则是，当企业不依赖或很少取决于其他服务时，就有独立的商业语义，为其他2个其他服务或客户提供数据，则应将其分为独立服务模块独立服务模块
这意味着每个微服务只需要实现自己的业务逻辑即可。例如，订单管理模块，它只需要处理订单的业务逻辑，而其他事情无需考虑。
这意味着每个微服务都独立于开发，测试，操作和维护，包括存储的数据库，并且它们也是独立的。我们有一组完整的流程。我们可以将其视为一个项目。无需依靠其他模块。
首先是交流语言非常轻巧。其次，通信方法需要进行跨语言和交叉平台。技术约束。
因为由于微服务的变化，因此可能会在设计开始时考虑所有情况，因此可能会在设计开始时考虑到其他微服务的调整，以避免调整其他微服务，因此该界面尽可能地尽可能地进行通用。更灵活，以免尽可能多地调整其他模块。
由于单个微服务模块等同于项目，因此我们只需要关心该模块的逻辑即可开发此模块。代码和逻辑复杂性将降低，易于开发和维护。
这是相对于单个微服务。与启动单个体系结构的整个项目相比，启动模块的服务速度显然要快得多。
我发现开发问题。如果是单个体系结构，我们需要发布并启动整个项目，这是非常时间的，但是微服务是不同的。哪个模块具有错误。我们只需要求解该模块的错误。解决该错误后，我们只需要重新启动该模块的服务即可。部署相对简单。无需重新启动整个项目，并节省时间。
例如，订单微服务和电影微服务最初是用Java编写的。现在，我们想将电影微服务更改为Nodejs Technology。这将少得多。
我们在上面说，当单个结构的性能即将扩大模块的性能时，我们必须考虑其他模块的性能是否会受到影响。对于我们的微服务，这根本不是问题。考虑其他模块的情况。
对于单个结构，我们只需要维护该项目，但是对于微服务体系结构，由于项目由多个微服务组成，因此每个模块的问题都会导致整个项目异常运行。通常不容易知道。哪个模块是由哪个模块引起的，因为我们不能逐步遵循调试，这提出了对操作和维护人员的高要求。
对于单个体系结构，我们不能使用分布式公式，但是对于微服务体系结构，分布式技术几乎是必要的技术。由于分布式本身的复杂性，微型服务体系结构也变得复杂。
例如，订单微服务和电影微服务需要用户微服务。一旦用户微服务的接口变化很大，调整接口的成本将大大增加。
对于单个结构，如果多个模块使用某个业务部分，我们可以将其抽象成工具类，并直接用所有模块来称呼它，但是微服务不能做到这一点，因为这个微服务工具类是谁不能成为由其他微服务部门直接调用，因此我们必须在每个微服务上构建这样的工具类，从而导致重复代码。
目前，微服务的开发框架是以下四个：以下四个：
春季靴子：
它旨在简化产品级别的弹簧应用程序和服务，简化配置文件，使用嵌入式Web服务器，包含许多解压缩，并使用微服务与Spring Cloud共同部署。
春天云：
Micro -Service工具软件包为开发人员提供了开发工具软件包，例如配置管理，服务发现，断路器，智能路由，微型代理，控制总线和分布式系统中的其他开发工具软件包。
在传统的开发方法中，所有服务都是本地的，可以直接调用UI，现在根据功能将其分为独立服务，并且在独立虚拟机上运行的Java流程通常是独立的虚拟机。他？背景中有N服务，前台需要记住管理N服务。一项服务是离线/更新/升级。前台必须重新占用。这显然不为我们服务。特别是，业务变化的节奏通常更快。此外，n个小型服务的呼吁也是一个小型网络的头顶。系统内部也有一般的微服务，通常没有状态。用户登录信息和权限管理应具有统一的地点维护管理（OAUTH）。
因此，它通常是N Services和UI之间的代理或API网关。他的角色包括
实际上，此API网关可以具有许多广泛的实施方式。它可能是一个硬且硬的框，一个简单的MVC框架，甚至是Node.js Server。他们最重要的作用是为前台（通常是移动应用程序）提供背景服务的聚合，提供一个统一的服务导出以减轻它们之间的耦合，但是API网关也可能是单点故障点或性能的瓶颈。
因为所有微服务都是独立的Java流程，在独立的虚拟机上运行，所以服务之间的段落是IPC（IPC INTER PROCESS COMLACONCE），并且已经有许多成熟的解决方案。基本上有两种方法基本上是最常见的方法。，可以写这本书，每个人通常都熟悉细节，因此我不会展示演讲。
通常，同时调用相对简单且一致，但很容易调用问题，并且性能经验会更糟，尤其是当呼叫级别较大时。静止和RPC的比较也是一个非常有意的主题。RESTP基于HTTP，该RESTP更容易实现，更容易被接受，并且服务端实施技术更加灵活。可以支持每种语言。同时，它可以跨越客户。可以调用客户的特殊要求，因此它相对较宽。RPC也有自己的优势。传输协议更有效和安全。特别是在公司内部。如果有统一的开发规范和统一的服务框架，他的发展效率优势更为明显。这取决于它们各自的技术积累和选择的实际条件。
异步消息的方法特别广泛地用于分布式系统中。他不仅可以减少低键呼叫服务之间的耦合，而且可以成为呼叫之间的缓冲区，以确保消息的积压不会被呼叫破坏。在同一方面的服务经验上，它继续运行，以免被背景性能放慢脚步。通常，背景服务通常会意识到力量和其他性别，因为信息会出现在性能方面。只有一个测试是对性能的很好的测试）；最后，有必要引入独立经纪人。如果公司内部没有技术积累，这对经纪人分布式管理也是一个巨大的挑战。
在微服务体系结构中，每个服务通常都有多个副本来使负载平衡。服务可能随时离线，或者也可能会增加临时访问压力中的新服务节点。如何互相感知？如何管理服务？这是服务发现的问题。通常有两种类型的实践，每种实践都有其自己的优势和缺点。从基本上，通过类似技术（例如Zookeeper）分发服务注册信息。当服务在线时，服务提供商已注册。其服务信息到ZK（或类似框架），并通过心跳保持长链接，以实时更新链接信息。服务呼叫者可以根据ZK的定制算法找到服务，并且服务信息可以还可以放心以提高性能。当服务离线时，ZK将向服务客户端发送通知。
客户端确实：优势是架构很简单，扩展是灵活的，并且仅取决于服务注册师。缺点是客户需要维护所有呼叫服务的地址。它有技术困难。通常，大公司具有成熟的内部框架支持，例如Dubbo。
服务器完成了：优势很简单，所有服务均对前台指挥官透明，并且通常使用在小公司中云服务上部署的更多应用程序。
分布式的最大特征是该网络不可靠。可以通过微服务降低这种风险，但是如果没有特殊保证，结局必须是一场噩梦。我们刚刚遇到在线故障是一个非常不起眼的SQL计数功能。当访问量增加时，数据库负载很高，影响了应用程序的性能，从而影响了调用此应用程序服务的所有前台应用程序。因此，当我们的系统由一系列服务呼叫链组成时，我们必须确保任何链接中的任何问题都不会影响整体链接。有许多相应的方法：
这是一个非常好的图片，总结了需要考虑的问题，包括
需要在服务之间创建服务发现机制，以帮助服务感知彼此的存在。当服务开始时，它将注册自己的服务信息到注册中心并订阅您需要消费的服务。
服务注册中心是服务发现的核心。它保留了每个可用服务实例的网络地址（iPaddress和port）。服务注册中心必须具有高可用性和真实的时间更新功能。注册中心。它提供了用于服务注册和查询服务信息的REST API。该服务通过使用POST请求来注册其自己的iPaddress和端口。通过get request.netflix的高可用性（Netflix实现高可用性）获得可用的服务实例信息是通过在Amazon EC2中运行多个实例来实现的。每个Eureka服务都有一个弹性IP地址。当Eureka服务启动时，会有DNS服务器的动态分配。EUREKA客户端以在正常情况下查询DNS。与客户在同一可用区域中的地址可用作服务注册中心::
简而言之，Zookeeper可以充当服务注册表，允许多个服务提供商组成一个集群，允许服务消费者通过服务注册表获得特定的服务访问地址（IP+端口），以访问特定的服务PROFISIONBY。如下所示。：
具体而言，Zookeeper是一个分布式文件系统。每当部署服务提供商时，它都必须将自己的服务注册到Zookeeeper：/{service}/{version}/{ip：port}，例如，我们的helloworldservice被部署到两台机器，然后将在Zookeeper上创建两个目录：/then/healloworldservice/1.0.0/100.19.20.20.01:16888/heellownervice/1.0/100.100.19.20.20.02:16888。
Zookeeper提供“心跳测试”功能，该功能将定期向每个服务提供商发送请求（实际上是插座长连接）。如果很长一段时间没有回应，服务提供商认为服务提供商已悬挂并消除它，例如100.19.20.02如果机器掉落，则Zookeeper上的路径只会左右 /helloworldservice /helloworldservice /1.0.0/100.19.20.01：16888。
服务消费者将收听相应的路径（/HelloworldService/1.0.0）。一旦路径上的数据具有任务更改（增加或减少），Zookeeper将通知消费者服务提供商的服务提供商地址列表以进行更新。
更重要的是，Zookeeper的固有容错和灾难的能力（例如领导者选举）可以确保服务注册表的高可用性。
为了确保高可用性，为了确保高可用性，每个微服务都需要部署多个服务示例以提供服务。这次，客户执行服务的负载平衡。
从Internet随机分配请求到其中的多个服务器。
网络中的每个请求都分配给内部服务器，从1到n，然后重新启动。此负载平衡算法适用于服务器内部的服务器具有相同的配置，并且平均服务请求相对平衡。
根据服务器的不同处理功能，将不同的权利值分配给每个服务器，以便他们可以接受相应的电源值的服务请求。例如：服务器A的权重为1，是1b为3，C的值为6，然后服务器A，B和C分别将获得10％，30％和60％的服务请求。Such平衡算法可以确保高性能服务器获得更多的用法和更多的用法和避免过多的低性能服务器。
该方法通过生成请求源IP的哈希值来找到正确的真实服务器，这意味着他的相应服务器对于同一主机始终相同。ip。但是，应注意的是，此方法可能导致服务器负载不平衡。
客户端上的每个请求服务在服务器停留时可能会有很大的差异。随着工作时间的延长，如果使用了简单的轮式或随机平衡算法，则每个服务器上的连接过程可能会产生很大的生成不同，它没有实现真正的负载平衡。至少，连接算法的数量具有数据记录需要加载内部的每个服务器。记录服务器正在处理的当前连接数。当新的服务连接请求时，当前请求将分配给最少连接数量的连接数量。服务器使余额更符合实际情况，负载更加平衡。此均衡算法合适对于长期请求服务，例如FTP。
故障后，对这个词的理解，面对您可以忍受错误的含义，并防止错误再次扩展，因此该错误的影响在固定的边界内。降级，电流，保险丝，随时间审查等都是耐耐剂的方法。
在调用服务群集时，如果微服务呼叫异常，例如超时，连接异常和网络异常等，则服务容错的耐受性基于错误 - 耐受策略。当前的支持服务错误策略失败了很快并且无法切换。如果它连续失败，它将直接断开并不再启动。这可以避免依赖于所有依赖他的服务的异常服务。
该服务仅启动一次，并且将立即报告失败。通常用于非功率和其他下属写作操作
该服务会启动呼叫，故障后，将检索其他服务器。通常用于阅读操作，但重试将带来更长的延迟。通常可以设置重试的数量
故障是安全的。当服务调用异常时，直接忽略它。它通常用于编写日志和其他操作。
当服务调用异常时，记录会失败并定期重置该请求。通常用于消息通知。
并行多个服务器，只要有一个成功，返回。通常用于高级阅读操作。您可以通过forks = n设置最大并行数字。
广播呼叫所有提供商，一个接一个地调用，任何故障失败。它通常用于通知所有提供商以更新本地资源信息，例如缓存或日志。
融合技术可以说是“智能的容错性”。当呼叫达到故障数时，故障比将触发保险丝打开。该程序会自动切断当前的RPC调用，以防止错误进一步扩展。保险丝的实现主要考虑三种模式，即关闭，打开，一半打开。每个状态的转换如下所示。
当我们处理异常时，我们必须根据特定业务状况确定处理方法。例如，我们将产品接口称为“产品接口”，而另一方仅暂时延迟处理。数据，友好提示。还应通过异常来区分类型，例如依赖服务的崩溃，这可能需要很长时间要解决它。这也可能是由于服务器负载的过时。作为保险丝，它应该能够识别此异常类型，以根据特定的错误类型调整FUSE策略。INCREASE手动设置，当失败服务恢复时间不确定时，管理员可以手动执行熔融状态。最后，保险丝的使用方案是远程服务程序或共享可能未能失败的资源。如果它是本地缓存本地私人资源，则保险丝的使用将增加系统的额外开销。还应注意，保险丝不能用作应用程序中业务逻辑的异常处理替代方案。
有一些异常的固执，突然发生，不可预测和难以恢复，这也会导致班级失败（例如，假设服务集群的负载很高。整个群集可能会受到影响）。如果我们此时继续重试，大多数结果都是失败的。此时，我们的应用程序需要立即进入故障状态（快速失败）并采用合适的恢复方法。
我们可以使用状态机实现断路器。它具有以下三个州：
SLA：服务级别的缩写，这意味着服务级别协议。它是网络服务提供商和客户之间的合同，该合同定义了诸如服务类型，服务质量和客户付款之类的术语。典型的SLA包括以下项目：
这里提到的网关是指API网关，这意味着所有API调用均连接到API网关层，并且网关层具有统一的访问和输出。网关的基本功能包括：统一访问，安全保护，安全保护，协议适应性，流量控制，长期链接支持，故障 - 耐耐受能力。网关后，每个API服务都可以专注于自己的业务逻辑处理，而API网关专注于安全，流量和路线等问题。
最简单的缓存是检查一次数据库，然后将数据写入缓存，例如REDIS并设置到期时间。由于有到期的故障，我们需要注意缓存的渗透率。渗透率。REDIS的比率为300/1000。以这种使用缓存的方式，有必要注意渗透率。渗透率表明缓存效果不好。使用缓存的另一种方法是持续缓存，也就是说，在不设定到期时间的情况下，这将面临数据更新问题。通常有两种方法。一种是使用时间戳将默认的redis查询为主。每次设置数据时，请放一个时间戳。每次阅读数据时，请使用当前时间和最后一个设置设置的时间戳。通常，这是DB的容错方法。另一个是真正使用redis，如db。那就是，datram的binlog绘制图中的数据库以通过数据异质系统将数据推向缓存，并且将设置缓存。要使用JVMCACHE作为应用程序中的第一个级别缓存，它的音量通常很小。较大的访问频率更适合这种JVMCACHE方法。一组Redis用作辅助远程缓存。
超时和重试机制也是一种容错的方法。发生RPC呼叫的任何人，例如阅读Redis，DB，MQ等导致线程会导致线程。口气，增加CPU负载，甚至导致Avalanche。因此，为每个RPC调用设置超时。推荐到1-2次。此外，总共发生了2个调用。如果超时时间是2s配置的，则客户必须等待4s返回。因此，超时时间应该很小。在这里，我们还谈论了PRC呼叫时间所消耗的链接。普通呼叫统计信息的时间消耗主要包括：①呼叫RPC框架执行时间+②网络发送时间+③服务终端RPC框架执行时间+ ServicePerform业务代码时间。呼叫者和服务方都有自己的性能监控。例如，呼叫者TP99为500ms，服务聚会TP99为100ms。我在网络小组中找到了一个同事，以确认网络没有问题。那么花费的时间在哪里？客户呼叫方有两个原因，一个原因之一是TCP由网络重新传输。因此请注意这两个点。
在此链接中，当Servlet3异步时，存在一个线程隔离。线程隔离的优点是防止关闭故障，甚至是雪崩。我们有呼叫订单，商品和用户。然后，该订单的命令不会影响商品和用户的请求处理。如果未完成线程隔离，当访问订单服务发生时，网络故障延迟了，并且积压了。线程最终将导致整个服务CPU已满。也就是说，我们说的所有服务都不可用，此刻将填充多少机器。不会影响整体情况。
减少电流的方法已经有成熟的方法。这里是我们的一些经验。降级通常是通过统一配置中心的降级开关来实现的。然后，当同一提供商有许多接口时，该提供商系统或该机器所在的机床的系统存在问题。我们必须具有统一的降级开关，否则我们必须通过接口和一个降级。界面。也就是说，有一把用于商务类型的大刀。还要降级暴力是降级的。什么是暴力降级？例如，论坛的功能减少了。结果，用户显示了一个大型白板。我们想慢慢保存一些数据，也就是说，有一个底部的数据。流量限制通常分为分布式流量限制和单位 - 单位电流。如果实现了分布式当前限制，则需要公共后端存储服务（例如REDIS）。LUA读取REDIS配置信息在大型NGINX节点上。我们的当前限制是一个单独的电流，我们尚未实现分布式电流。
API网关是一个串行通话，因此必须记录并存储每个步骤的异常情况，例如在plasticserach中的一个地方，这很方便，可以随后分析呼叫异常。在分发之前存在于Docker上，它不再允许增加。我们已经实施了一个代理程序来收集服务器上的日志输出，然后将其发送到Kafka群集，然后将其消耗到plasticserach，然后通过查询Web。现在的跟踪功能相对简单，并且该作品需要继续丰富。