eureka

​ ​ 上一篇 通过自己搭建zipkin的方式实现分布式链路跟踪，但没有将请求服务的链路信息存储到数据库，以下通过RabbitMQ实现Zipkin持久化到Mysql8。使用zipkin 2版本提供了 jar包启动应用。 Java 8及以上版本 Spring Cloud Hoxton.SR8 RabbitMQ 3.8.9 Erlang 23.1.1 zipkin-server-2.22.2 Mysql8 一、搭建Zipkin Server ​ mac中安装 RabbitMQ ​ 1. 安装Erlang，执行brew install erlang命令。 ​ 2. 安装RabbitMQ Server，执行 brew install rabbitmq命令。 ​ 进入目录/usr/local/sbin，执行rabbitmq-server，访问RabbitMQ http://localhost:15672 #guest guest ​ 创建一个名为 zipkin 的数据库，从Github下载 zipkin 的 sql语句 ，导入数据库。 ​ 下载zipkin-server包 ，执行如下指令启动zipkin应用。 java -jar zipkin-server-2.22.2-exec.jar --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL

我是来自微医集团消费事业群的前端工程师高翔，这篇文章整理自我在《第一届缤纷前端技术沙龙》的主题分享《Node.js 在医疗行业的应用》，介绍了 Node.js 在微医的发展历程和应用实践经验。 微医是总部位于杭州萧山的一家互联网医疗公司，我们的前端研发人员从2015年的几个人发展到现在的120多人，前端技术栈体系发生了巨大的变化，下面这张图展示了我们部门前端团队的技术栈演进过程。 16年之前主要是前后端耦合的开发方式。 17年开始引进 Vue，进行前后端分离，并开始尝试做 Vue SSR 的探索。 18年全面推 Vue SSR，积累了一定的 Node.js 经验，出现了越来越多的线上 Node.js 应用。 今年主要是将之前的解决方案沉淀下来，变成框架、文档、插件、脚手架等，来更好的支持需求的迭代。 可以看到在微医， Node.js 在线上应用起步较晚，但是发展很快，例如消费线业务基本都迁移到了 SSR 技术体系。 下面 这张图是我们公司前端应用的分布情况。 可以看到，集团总体前端应用中，Node.js 应用大概占比 1/4，而在 Node.js 应用中主要是 SSR 应用，其次是一些全栈体系的内部应用，接着是一些 API 服务，做一些接口的聚合和转发。 所以我今天主要从 Vue SSR、内部应用和 API 服务来介绍一下 Node.js 在微医的使用情况。 应用场景一：内部工具

前言 Spring Cloud是微服务架构开发的完美解决方案，它是一套分布式服务治理的框架，专注于全局微服务协调整理，可以将各个单独的微服务整合并管理起来，为各个微服务之间提供配置管理、服务发现、断路器、路由、消息代理、事件总线、决策竞选、分布式会话等集成服务。 Spring Cloud本身不提供具体功能性的操作，更专注于服务之间的通信、熔断和监控等，因此就需要很多组件来支持完整功能。 开发、部署和运营云应用程序应该像本地应用程序一样简单。这应该是任何云平台、库或工具背后的管理原则。Spring Cloud可以轻松地为云开发JVM应用程序。 本文将介绍Spring Cloud并帮助开发人员掌握其功能。 本文首先介绍如何配置Spring Cloud服务器并运行Eureka服务器以启用服务注册和发现;然后再深入剖析与负载均衡和断路相关的技术，包括利用Feign客户端的所有功能; 最后讨论和研究高级主题，包括如何为Spring Cloud实现分布式跟踪解决方案并构建消息驱动的微服务架构。 本文将带大家从零开始一步步精通springcloud微服务架构，能够灵活运用到工作中，不断地提升自己的技术深度和宽度，让自己变得更有价值，也希望本文能够帮助到大家的学习！！ 目录 主要内容 本文详细阐述了与Spring Cloud微服务框架相关的基本解决方案，主要包括微服务简介、使用微服务的Spring

原文：https://4m.cn/hXBqK 我们先认识一下SpringCloud的各个组件，然后知其所以然。 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好

场景： 　　在启动eureka server时，出现以下错误： （这个错误也不影响启动，每次启动都报这个错误，感觉不太好） 　com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused: connect 　　com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server 　　　　at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:111) ~[eureka-client-1.6.2.jar:1.6.2] 方法一： 　　在默认设置下，eureka服务注册中心也会将自己作为客户端来尝试注册它自己，所以我们需要禁用它的客户端注册行为: eureka.instance.hostname=localhost eureka.client.register-with-eureka=false eureka.client.fetch-registry

Fizz 网关简介 Fizz Gateway 是一个基于 Java开发的微服务网关，能够实现热服务编排、自动授权选择、线上服务脚本编码、在线测试、高性能路由、API审核管理等目的，拥有强大的自定义插件系统可以自行扩展，并且提供友好的图形化配置界面，能够快速帮助企业进行API服务治理、减少中间层胶水代码以及降低编码投入、提高 API 服务的稳定性和安全性。 整体架构 Fizz网关的核心处理流程如上图, 收到客户端的请求后会经过一系列内置或自定义的过滤器，接着网关会自动判断当前请求的接口是否是服务编排接口，如果是服务编排接口就根据配置文件创建一个pipeline，在服务编排的pipeline里可以实现接口的串联或并联调用，可以对输入和输出的内容做数据转换，字段映射，脚本处理等操作；如果不是服务编排接口则直接反向代理到后端服务，最后把响应结果返回给客户端。 主要功能特性 - 集群管理：Fizz网关节点是无状态的，配置信息自动同步，支持节点水平拓展和多集群部署。 - 服务编排：支持热服务编排能力，支持前后端编码，随时随地更新API。 - 负载均衡：支持round-robin负载均衡。 - 服务发现：支持从Eureka注册中心发现后端服务器。 - 配置中心：支持接入apollo配置中心。 - HTTP反向代理：隐藏真实后端服务，支持 Rest API反向代理。 - 访问策略

一提到注册中心，大家往往想到Zookeeper、或者Eureka。今天我们看看阿里的一款配置中心+注册中心的中间件——Nacos。有了它以后，我们的项目中的配置就可以统一从Nacos中获取了，而且Spring Cloud的提供者和消费者还可以使用它做注册发现中心。 在搭建Nacos的时候，为了保证高可用，我们要采用的集群的方式搭建。 首先，我们要在数据库中创建一些Nacos的表，Sql文件可以点击下面的链接下载， Sql文件 然后，我们再下载Nacos的压缩包，连接如下： tar.gz包 将下载好的压缩包分别上传到3个服务器上，在我们这里3台机器分别是192.168.73.141，192.168.73.142，192.168.73.143，然后进行解压， tar -zxvf nacos-server-1.3.2.tar.gz 然后，我们进入到conf目录，修改配置，如下： vim application.properties #*************** Config Module Related Configurations ***************# ### 数据源指定MySQL spring.datasource.platform=mysql ### 数据库的数量: db.num=1 ### 数据库连接 IP 端口 数据库名称需要改成自己的 db.url.0

spring cloud本身提供的组件就很多，但我们需要按照企业的业务模式来定制企业所需要的通用架构，那我们现在需要考虑使用哪些技术呢？ 下面我针对于spring cloud微服务分布式云架构做了以下技术总结，希望可以帮助到大家： View： H5、Vue.js、Spring Tag、React、angularJs Spring Boot/Spring Cloud： Zuul、Ribbon、Feign、Turbine、Hystrix、Oauthor2、Sleuth、API Gateway、Spring Cloud、Config Eureka、SSO、Spring Cloud、 BUS、Turbine、Zipkin、Cache、Spring Cloud Admin、API Gateway、ELK Spring Cloud Security、 Spring Cloud Stream Component： RoketMQ、Kafka、MongoDB、OSS、Redis、Swagger、Zuul、Label、BASE、Charts、Utils DAO： Spring Data、Mybatis、OSS、 DTO Data Storage： RDBS DFS、NOSQL/Hadoop Infrastructure： LogBack、BUS、Jenkins、Zipkin、Druid

Cloud-Admin是国内首个基于Spring Cloud微服务化开发平台，具有统一授权、认证后台管理系统，其中包含具备用户管理、资源权限管理、网关API管理等多个模块，支持多业务系统并行开发，可以作为后端服务的开发脚手架。代码简洁，架构清晰，适合学习和直接项目中使用。核心技术采用Spring Boot2以及Spring Cloud Gateway相关核心组件，前端采用vue-element-admin组件。 模块说明 监控 利用Spring Boot Admin 来监控各个独立Service的运行状态；利用Hystrix Dashboard来实时查看接口的运行状态和调用频率等。 负载均衡 将服务保留的rest进行代理和网关控制，除了平常经常使用的node.js、nginx外，Spring Cloud系列的zuul和ribbon，可以帮我们进行正常的网关管控和负载均衡。其中扩展和借鉴国外项目的扩展基于JWT的Zuul限流插件，方面进行限流。 服务注册与调用 基于Eureka来实现的服务注册与调用，在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。 熔断机制 因为采取了服务的分布，为了避免服务之间的调用“雪崩”，采用了Hystrix的作为熔断器

1、JVM内存区域 本地方法栈、Java虚拟机栈、程序计数器、堆、元空间、直接内存 2、程序计数器的作用 程序计数器是一块较小的内存空间，它的作用可以看作是当前线程所执行的字节码的行号指示器。这里面存的，就是当前线程执行的进度。 3、字符串常量位于哪个区域 字符串常量池，jdk8之前是perm区，jdk8及以后是在堆上面。 类文件常量池，是位于方法区，也就是元空间。 4、类加载的过程 加载 验证 准备（为一些类变量分配内存，并将其初始化为默认值） 解析（将符号引用替换为直接引用） 初始化 5、类加载器 Bootstrap ClassLoader（启动类加载器） Extention ClassLoader（扩展类加载器） App ClassLoader（应用类加载器） 6、双亲委派是可以被违背的吗？ 可以。需要重写ClassLoader#loadClass和ClassLoader#findClass实现。 7、Tomcat类加载 可以看这篇： https://www.cnblogs.com/aspirant/p/8991830.html 8、垃圾收集算法 标记清除（碎片化） 复制算法（浪费空间） 标记整理算法（效率比前两者差） 分代收集算法（老年代一般使用“标记-清除”、“标记-整理”算法，年轻代一般用复制算法） 9、为什么年轻代用复制算法 因为年轻代存活的对象比较少