上次写了一篇文章叫Spring Cloud在国内中小型公司能用起来吗?介绍了Spring Cloud是否能在中小公司使用起来，这篇文章是它的姊妹篇。其实我们在这条路上已经走了一年多，从16年初到现在。在使用Spring Cloud之前我们对微服务实践是没有太多的体会和经验的。从最初的开源软件云收藏来熟悉SpringBoot，到项目中的慢慢使用，再到最后全面拥抱Spring Cloud。这篇文

微服务之分布式跟踪系统（springboot+zipkin）一、zipkin是什么        zipkin是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。它的理论模型来自于GoogleDapper 论文。        每个服务向zipkin报告计时数据，zip

前言在前面的博客中，我们将服务注册到了Eureka上，可以从Eureka的UI界面中，看到有哪些服务已经注册到了Eureka Server上，但是，如果我们想查看当前服务提供了哪些RESTful接口方法的话，就无从获取了，传统的方法是梳理一篇服务的接口文档来供开发人员之间来进行交流，这种情况下，很多时候，会造成文档和代码的不一致性，比如说代码改了，但是接口文档没有改等问题，而Swagger

Hbase全称为Hadoop Database，即hbase是hadoop的数据库，是一个分布式的存储系统。Hbase利用Hadoop的HDFS作为其文件存储系统，利用Hadoop的MapReduce来处理Hbase中的海量数据。利用zookeeper作为其协调工具。 本篇文章将重点介绍Hbase三个方面的内容：Hbase体系结构（架构）的介绍、Hbase shell的操作、Hbase的Jav

摘要： 本文简单介绍了如何利用Zipkin对SpringCloud应用进行服务分析。在实际的应用场景中，Zipkin可以结合压力测试工具一起使用，分析系统在大压力下的可用性和性能。设想这么一种情况，如果你的微服务数量逐渐增大，服务间的依赖关系越来越复杂，怎么分析它们之间的调用关系及相互的影响？服务追踪分析一个由微服务构成的应用系统通过服务来划分问题域，通过REST请求服

1、ApplicationContextSpring的核心，Context我们通常解释为上下文环境。ApplicationContext则是应用的容器。 Spring把Bean（object）放在容器中，需要用就通过get方法取出来。在ApplicationContext接口的众多实现类中，有3个是我们经常用到的（见表1-1），并且使用这3个实现类也基本能满足我们Java EE应用开发中的绝大部.

Q:一个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费synchronizedlockdb lockQ：两个业务服务器，一个数据库，操作：查询用户当前余额，扣除当前余额的3%作为手续费分布式锁我们需要怎么样的分布式锁？可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。这把锁要是一把可重入锁（避免死锁）这把锁最好是一把

public static String postURL(String commString, String address, String encode) {String rec_string = "";URL url = null;HttpURLConnection urlConn = null;try {/*得到

这里先简单介绍下我的项目里面的基本使用，redis服务采用的是三主三从模式。1、配置文件代码如下：package com.whb.redisson.demoOne.properties;import org.redisson.config.ClusterServersConfig;import org.springframework.boot.context.properties.C

5、场景应用——电商平台：浏览记录收集功能事件/日志收集系统是大中型软件不得不面对的话题。目前第三方业务系统对 事件/日志收集系统 的集成思路主要有两大类：侵入式收集方案和非侵入式收集方案。侵入式收集方案，是指任何需要使用事件/日志收集系统的第三方系统，都需要做有针对的编码工作，这个编码工作或者是新增代码用于调用 事件/日志收集系统 提供的客户端API，又或者是修改已有的代码，以便适应事件