Spring Cloud

服务端配置： eureka : instance : ip-address : 111.*.*.* # 决定 Eureka 服务显示 host hostname : ${ eureka.instance.ip-address } # 决定服务跳转 host ，必须指定 prefer-ip-address : true non-secure-port : ${ server.port } instance-id : ${ eureka.instance.ip-address }:${ server.port } client : service-url : defaultZone : http://111.*.*.* :8761/eureka/ register-with-eureka : true 来源： oschina 链接： https://my.oschina.net/xyzuncle/blog/3166422

Zipkin服务追踪原理 创造一些追踪标识符（tracingId，spanId，parentId），最终将一个request的流程树构建出来，各业务系统在彼此调用时，将特定的跟踪消息传递至zipkin,zipkin在收集到跟踪信息后将其聚合处理、存储、展示等，用户可通过web UI方便获得网络延迟、调用链路、系统依赖等等。 transport作用：收集被trace的services的spans，并将它们转化为zipkin common Span，之后把这些Spans传递的存储层 collector会对一个到来的被trace的数据（span）进行验证、存储并设置索引(Cassandra/ES-search/Memory) Zipkin基本概念&核心数据结构 Annotation（用途：用于定位一个request的开始和结束，cs/sr/ss/cr含有额外的信息，比如说时间点）： cs：Client Start,表示客户端发起请求一个span的开始 sr：Server Receive,表示服务端收到请求 ss：Server Send,表示服务端完成处理，并将结果发送给客户端 cr：Client Received,表示客户端获取到服务端返回信息一个span的结束，当这个annotation被记录了，这个RPC也被认为完成。客户端调用时间=cr-cs，服务端处理时间=sr-ss。 Span

Eureka Eureka是 Netflix 的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了 服务发现与注册 ，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心比如Zookeeper，Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现。 Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心，使用 Eureka 的Client连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑，如下图所示： 集成Eureka服务 1 配置 Eureka服务端， application.yml配置 server: port: 7001 eureka: instance: hostname: localhost #eureka服务端的实例名称 client: register-with

有时候在配置中心有些参数是需要修改的，这时候如何不重启而达到实时生效的效果呢？ 本文基于以下讲解： Spring Cloud Greenwich.SR3 Spring Boot 2.1.7.RELEASE 基于 Git 的配置中心仓库 添加 actuator 依赖 在引用配置中心的项目中添加以下 actuator 依赖： <dependencies> ... <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> ... </dependencies> spring-boot-starter-actuator ：这个模块的 /actuator/refresh (POST请求)端点可以刷新配置，更多的使用参考 Spring Boot 系列文章。 暴露 refresh 端点 actuator 默认是不暴露 refresh 端点的，需要我们主动暴露，在引用配置中心的项目中添加以下配置： management: endpoints: web: exposure: include: refresh,info,health 添加刷新范围 引用了配置中心的项目，在需要刷新的 Bean 上添加

经过仔细检查，全部配置映射都没问题，springboot-admin 监控中心所有服务状态全部显示绿色正常 但就是通过 zuul 访问服务提示 500错误 这个情况，一般是请求超时所致 调整请求超时时间即可 zuul服务本地报错提示：com.netflix.zuul.exception.ZuulException: Forwarding error 原始配置示例： hystrix: command: default : execution: isolation: thread: timeoutInMilliseconds: 12000 ribbon: ReadTimeout: 6000 ConnectTimeout: 6000 zuul: host: socket-timeout-millis: 6000 connect-timeout-millis: 6000 from www .1 b23.com 全部改成： hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 12000 ribbon: ReadTimeout: 12000 ConnectTimeout: 12000 eureka: enabled: true zuul: host: socket-timeout

本文是《微服务治理解密》系列篇的第一篇文章，为大家介绍 EDAS 是什么。该系列文章基于阿里云商业化产品 EDAS 『产品官网 >>』 的微服务实践，如果你的团队具备较强的微服务治理能力，那么希望我们在微服务治理方面的实践和背后的思考，可以为你提供一些参考。 EDAS 是什么 有很多读者问我在阿里是做什么的，我一般会回答：“我在阿里主要负责 Dubbo、HSF、SpringCloud Alibaba 这几个微服务框架研发和商业化相关的工作”，这样回答，如果对方是 Java 开发，一般都能知道个大概。熟悉阿里云的朋友会了解到阿里云上有很多的 PaaS 产品，我主要就是负责开发 “企业级分布式应用服务 EDAS” 这款产品；不熟悉阿里云的朋友，会对阿里云上一堆产品、一堆名词感到奇怪，什么 EDAS、MSE、ACM、OAM… 我开始接触 EDAS 时，也是吐槽了一下这次名词，但随着逐渐了解，也就觉得这些云产品像 Redis、DB、MQ 这些东西一样亲切了。这篇文章将围绕 EDAS 这款阿里云云产品进行介绍。 企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）是一个应用托管和微服务管理的 PaaS 平台，提供应用开发、部署、监控、运维等全栈式解决方案，同时支持 Spring Cloud、Apache Dubbo（以下简称

 我的博客： 程序员笑笑生 ,欢迎浏览博客！  上一章 SpringCloud 基础教程(十一)-Sleuth 调用链追踪简介 当中，我们将介绍了Spring Cloud Sleuth在分布式环境中实现了调用链路信息的打印，本章将在此基础之上结合Zikpin搭建完整的实时数据追踪系统。 前言  Zipkin是一款分布式追踪系统，是用来收集并诊断微服务体系中系统延时问题，主要功能就是收集和查找这些问题，Spring Cloud Sleuth实现了Dapper(Google 分布式跟踪系统的论文)，生成了一系列的追踪数据，当然也能集成Zipkin，聚集日志到Zipkin中，由Zipkin收集并存储，以及提供查询等功能 一、Zipkin简介  Zipkin主要由4个部分组成，如下图: 收集器：Collector 存储器：Storage，默认是内存存储，我们可以改成数据库如Mysql等 查询：提供RESTful的api提供查询 Web界面：单独的UI组件 二、快速使用  Zipkin分为服务端和客户端，服务端就是单独的一个Zipkin服务，用来收集、展示信息用的，而客户端在微服务架构中就是每个微服务的组件，我们在每个组件中配置Zipkin服务端的连接地址URL，就可以将追踪信息传输给Zipkin。传输采用的事HTTP请求，当然也可以改成消息总线的方式. 2.1 搭建Zipkin服务端

架构设计的目的 架构设计的主要目的：是为了解决软件系统复杂度带来的问题 。 个人感悟是：架构即(重要)决策，是在一个“ 有约束的盒子 ”里去求解或接近最优解。这个“ 有约束的盒子 ”是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人，财，物，时间，事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。 软件系统复杂度 软件领域的复杂性 体现在两个方面： 1. 结构的复杂性 结构复杂的系统几乎毫无例外具备两个特点： 组成复杂系统的组件数量更多； 同时这些组件之间的关系也更加复杂。 2. 逻辑的复杂性 意识到结构的复杂性后，我们的第一反应可能就是“降低组件数量”，毕竟组件数量越少，系统结构越简。最简单的结构当然就是整个系统只有一个组件，即系统本身，所有的功能和逻辑都在这一个组件中实现。 不幸的是，这样做是行不通的，原因在于除了结构的复杂性，还有逻辑的复杂性，即如果某个组件的逻辑太复杂，一样会带来各种问题。 逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能。 架构设计三原则 1 合适原则： 合适优于业界领先 架构无优劣，但存合适性。“汝之蜜糖，吾之砒霜”；架构一定要匹配企业所在的业务阶段；不要面向简历去设计架构，高大上的架构不等于适用；削足适履与打肿充胖都不符合合适原则；所谓合适，一定要匹配业务所处阶段

发文以来，分享了一些科技资讯，今天首次整理一些开源项目分享。既是对自己的学习督促，也是对有需要人的一种便利。 开源项目一： mall商城 star数：29.8k 项目地址：https://github.com/macrozheng/mall mall项目是一套电商系统，包括前台商城系统及后台管理系统，基于SpringBoot+MyBatis实现，采用Docker容器化部署。 前台商城系统包含首页门户、商品推荐、商品搜索、商品展示、购物车、订单流程、会员中心、客户服务、帮助中心等模块。 后台管理系统包含商品管理、订单管理、会员管理、促销管理、运营管理、内容管理、统计报表、财务管理、权限管理、设置等模块。 开源项目二： 微人事人力资源管理系统，SpringBoot+Vue开发 star数：14k 项目地址：https://github.com/lenve/vhr 开源项目三： Spring-boot-pay支付项目 star数：5.2k 项目地址：https://gitee.com/52itstyle/spring-boot-pay 开源项目四： Spring-boot-seckill分布式秒杀系统 star数：6.4k 项目地址：https://gitee.com/52itstyle/spring-boot-seckill 开源项目五： Spring-boot-mail邮件服务

公司规划的分销模式很多，有通用三级分销模式、分享一级分润模式、店铺推荐收益模式、商品分享直接收益模式等。 来源： oschina 链接： https://my.oschina.net/u/3613013/blog/3171701