haoyun的博客

微服务是一种架构风格，将业务拆分成模块，部署在不同的主机上提供结构，提供服务，通过http的方式通信单体应用架构（All in One）将一个应用的所有应用服务都封在一个应用中，无论什么系统，都把数据库访问，web访问，各个功能放在一个war包内这样的好处是方便开发测试，部署十分容易，需要扩展时只要把war包复制多份，然后放到多个服务器上在做个负载均衡缺点是，哪怕要修改任何一个地方，都要停掉整个服务，重新打包、部署这个应用的war包，特别对于一个大型的应用，不可能把所有内容都放在一个应用里面，如

Swagger简介前后端分离后端：后端控制层、服务层、数据访问层前端：前端控制层、视图层前端伪造数据，json，不需要数据也能跑起来前后端如何交互===》通过API沟通前后端相对独立，送耦合前后端甚至可能部署在不同的服务器上产生一个问题前后端集成联调，前后端无法做到即时协商，前端加了字段后端需要更改很多东西解决方案指定Schema计划制定的提纲，实时更新最新的API，降低集成风险早些年使用Word文档前后端分离前端要使用数据时要确保数据适合前端界面，如果后端传递

微服务概述之前马丁的文章微服务优缺点微服务优点：单一职责服务内聚，足够小，代码容易理解，聚焦单一业务功能需求松耦合，开发阶段部署阶段都是独立的能使用不同的语言开发，因为基于轻量级通信易于第三方集成，微服务容易灵活部署，持续集成工具：jenkins、Hudson、bamboo容易理解修改维护只是业务逻辑代码每个微服务都有自己的存储能力，可用有自己的数据库，或使用统一数据库缺点：要处理分布式系统的复杂性多服务运维难系统部署依赖服务间通信成本数据一致性系统集成测试性能监

SpringCloud版本选择建议使用F或G开头的创建项目需要的工作maven设置打包方式导入依赖文本SpringCloud，provider和consumer都需要加spring-cloud包，并且要设置<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifa

Eureka集群多个注册中心保证安全，每个Eureka注册中心去关联其他的注册中心defaultZoon：服务url用逗号分隔就行provider端，也加多个集群配置遇到Bug：集群列表没显示其他Eureka服务器解决方法尝试修改applicaiton service-url.defaultZone集群的多台服务器都在本地部署，被判定为同一台服务器，修改eureka.instance.hostname禁用虚拟网卡，前两个方法有实际用处提供者端，绑定，换行，导致未找到第三台Eur

Eureka对比Zookeeper根据CAP原则，P（Partition tolerance）分区容错性必须保证，所以只能再CA中选择Zookeeper保证CPEureka保证APACID原则A（Atomicity）原子性C（Consistency）一致性I（Isolation）隔离性D（Durability）持久性CAP原则C（consistency）强一致性A（Availability）可用性P（Partition tolerance）分区容错性R

详细内容我上一篇文章写了无法访问的情况遇到的Bug三个provider的spring.application.name不一致，导致consumer访问不到报错Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.IllegalStateException:

自定义负载均衡loadblancer负载均衡包下有一个IRule接口几个实现类，分别是抽象的负载均衡角色获取负载均衡的默认实现可过滤角色public class RoundRobinRule extends AbstractLoadBalancerRule {轮询是比较常用的负载均衡算法，集成于AbstractLoadBalancerRule，所以基于这个来模仿一个自定义负载均衡几个会用到的源码的方法，获取服务个数，下一个服务/*选择

FeignFeign接口方式并没有成功，尝试了并没有成功2020年10月16日再次尝试，成功，Success！Feign的声明式的web service客户端，它让微服务之间调用更加简单，类似controller调用service，SpringCloud集成了Ribbon和Eureka，可在使用feign时提供负载均衡的http客户端只要创建一个借口添加注解Ribbon通过微服务名字访问feign通过接口访问版本问题原因版本问题，不同的版本导致使用的代码可能不同重新选择springboo

服务熔断分布式系统面临的问题：复杂的分布式体系结构中的应用 程序有数十个依赖关系，一个应用里面有多个功能，功能与功能之间有依赖关系，功能如果出现错误，产生等待，整条线就会卡死，服务熔断就是在这些功能中如果产生错误，避免集联故障，一个功能可以没有但是不能让他影响整条线的运行服务雪崩服务之间的相互依赖，称为“扇出”，在闪出链路上，某个微服务的调用响应时间过长或不可用，微服务调用就会占用更多的资源，引起系统崩溃，所谓雪崩效应对于高流量的应用来说，单一的后端依赖可能导致所有服务器上的资源在几秒钟内饱

服务降级​ 因为Feign项目的不成功，导致服务降级也无法完成​ 问题已解决，版本问题根据实际业务情况以及流量，对一些服务喝页面有策略的不处理或换简单的方式处理，从而释放服务器资源以保证核心服务正常运作或高效运作使用场景：当负载超过了预设的阀值或流量超出预计，保证重要的服务能正常运行，将不紧急，不重要的服务延迟使用或暂停使用核心设计服务降级-分布式开关超时降级：设定超时重试次数和机制，使用异步机制探测恢复情况失败次数降级：一些不稳定的API，当失败次数达到一定阀值，自动降级，

Hystrix_DashboardDashboard 仪表盘，一个服务熔断的实时监控工具，可直观的看到hystrix Command的请求响应，请求成功率主要操作：一个HystrixDashboard客户端设置端口为9001添加依赖文本hystrix-dashboard<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spr

Zuul路由网关Zuulzuul包含了对请求的路由和过滤的两个主要的功能路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础过滤器对请求的处理进行干预，请求校验，服务聚合等功能的基础Zuul和Eureka整合，注册在Eureka服务下，从Eureka中获取其他微服务的消息以后访问微服务通过Zuul跳转后获得真是的微服务地址隐藏起来DemoZuul-9527主要流程：导入两个依赖文本，zuul、Eureka启动类开启zuul支持配置&l

SpringCloudConfigconfigClientconfigServer远程服务器git概述：分布式配置问题，将单体服务拆分成多个微服务，系统产生大量微服务，每个服务都需要配置，SpringCloud Config对微服务配置进行统一管理，三种角色，configClient对应每个微服务，连接configServer，统一从server连接到远端云进行统一管理配置中心可以连接本地，也可以连接远程，客户端对应着一个一个的微服务可以设置多个环境来动态化配置更新，/dev环境/te