scservers(十一)监控管理-日志调用链跟踪管理

前言

微服务会讲业务根据实际需要按照一定的粒度将业务拆分成一个个服务,相互之间也会存在调用关系,当系统庞大复杂到一定程度后,调用关系的复杂导致请求变慢或者不可用的时候,查找问题也变得复杂困难,不像单体应用,在一个地方查看下日志就ok.这时我们就需要将相应的调用链成串,就需要分布式系统日志调用跟踪管理来进行日志数据的治理。

现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,使用最为广泛的开源实现是 Twitter 的 Zipkin,为了实现平台无关、厂商无关的分布式服务跟踪,CNCF 发布了布式服务跟踪标准 Open Tracing。

Open Tracing标准

  • Span: 基本工作单元,例如,在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC,span通过一个64位ID唯一标识,trace以另一个64位ID表示,span还有其他数据信息,比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)

span在不断的启动和停止,同时记录了时间信息,当你创建了一个span,你必须在未来的某个时刻停止它。

  • Trace: 一系列spans组成的一个树状结构,例如,如果你正在跑一个分布式大数据工程,你可能需要创建一个trace。

  • Annotation: 用来及时记录一个事件的存在,一些核心annotations用来定义一个请求的开始和结束

  • cs – Client Sent -客户端发起一个请求,这个annotion描述了这个span的开始 sr – Server Received -服务端获得请求并准备开始处理它,如果将其sr减去cs时间戳便可得到网络延迟 ss – Server Sent -注解表明请求处理的完成(当请求返回客户端),如果ss减去sr时间戳便可得到服务端需要的处理请求时间 cr – Client Received -表明span的结束,客户端成功接收到服务端的回复,如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

概念

一般来说,一个分布式服务跟踪系统主要由三部分构成:

  • 数据收集
  • 数据存储
  • 数据展示

    ### 组成
  • Rabbitmq: 消息队列,主要用于传输日志
  • Zipkin: 服务调用链路追踪系统,聚合各业务系统调用延迟数据,达到链路调用监控与跟踪。

    服务调用链路
  • Sleuth 作为Zipkin客户端按照Open Tracing标准收集日志信息,可以通过http或者mq将日志传递到Zipkin Server 并存储起来
  • ES + Kibana提供搜索、查看和与存储在 Elasticsearch 索引中的数据进行交互的功能。开发者或运维人员可以轻松地执行高级数据分析,并在各种图表、表格和地图中可视化数据。
  • Grafana可视化图表监控工具,按照规则将数据库信息进行可视化处理,进行统计图表等的展现。

    Zipkin

    Zipkin 是 Twitter 的一个开源项目,它基于 Google Dapper 实现,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。

    我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外,它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。

    Zipkin 提供了可插拔数据存储方式:In-Memory、MySql、Cassandra 以及 Elasticsearch。接下来的测试为方便直接采用 In-Memory 方式进行存储,生产推荐 Elasticsearch。

    上图展示了 Zipkin 的基础架构,它主要由 4 个核心组件构成:

    • Collector:收集器组件,它主要用于处理从外部系统发送过来的跟踪信息,将这些信息转换为 Zipkin 内部处理的 Span 格式,以支持后续的存储、分析、展示等功能。
    • Storage:存储组件,它主要对处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,我们也可以修改此存储策略,通过使用其他存储组件将跟踪信息存储到数据库中。
    • RESTful API:API 组件,它主要用来提供外部访问接口。比如给客户端展示跟踪信息,或是外接系统访问以实现监控等。
    • Web UI:UI 组件,基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。

    Spring Cloud Sleuth

    Spring Cloud Sleuth 为服务之间调用提供链路追踪。通过 Sleuth 可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外 Sleuth 可以帮助我们:

    • 耗时分析: 通过 Sleuth 可以很方便的了解到每个采样请求的耗时,从而分析出哪些服务调用比较耗时;
    • 可视化错误: 对于程序未捕捉的异常,可以通过集成 Zipkin 服务界面上看到;
    • 链路优化: 对于调用比较频繁的服务,可以针对这些服务实施一些优化措施。

      Spring Cloud Sleuth 可以结合 Zipkin,将信息发送到 Zipkin,利用 Zipkin 的存储来存储信息,利用 Zipkin UI 来展示数据。

    这是 Spring Cloud Sleuth 的概念图:

使用

Zipkin 服务端

我们使用rabbitmq 作为传输信息的方式使用日志跟踪系统

springcloud 2.0 之后不再简易自定义Zipkin服务端,所以我们直接使用Zipkin-server jar包进行。

如下方式启动,就可以从rabbit_address获取日志消息了

RABBIT_ADDRESSES=localhost java -jar zipkin.jar
  • docker的使用配置

    • 依赖消息通信
    version: '3'
    services:
    rabbitmq:
    image: rabbitmq:alpine
    container_name: sc-rabbitmq
    restart: always
    volumes:
    - ./data/rabbitmq:/var/lib/rabbitmq
    networks:
    - sc-net
    ports:
    - 5672:5672
    • zipkin-server
    zipkin-server:
    image: openzipkin/zipkin
    container_name: sc-zipkin-server
    restart: always
    volumes:
    - ./data/logs/zipkin-server:/logs
    networks:
    - sc-net
    ports:
    - 9411:9411
    environment:
    - RABBIT_ADDRESSES=rabbitmq:5672
    - RABBIT_MQ_PORT=5672
    - RABBIT_PASSWORD=guest
    - RABBIT_USER=guest
    • ES + Grafana
    version: '3'
    services:
    elasticsearch:
    image: elasticsearch:alpine
    container_name: sc-elasticsearch
    restart: always
    volumes:
    - ./data/elasticsearch/logs:/var/logs/elasticsearch
    networks:
    - sc-net
    ports:
    - 9200:9200
    kibana:
    image: kibana
    container_name: sc-kibana
    restart: always
    volumes:
    - ./data/kibana/logs:/var/logs/kibana
    networks:
    - sc-net
    ports:
    - 5601:5601
    environment:
    - ELASTICSEARCH_URL=http://elasticsearch:9200
    depends_on:
    - elasticsearch
    grafana:
    image: grafana/grafana
    container_name: sc-grafana
    restart: always
    volumes:
    - ./data/grafana/logs:/var/logs/grafana
    networks:
    - sc-net
    ports:
    - 3000:3000

客户端

  • 依赖
<!--自省和监控的集成功能-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <!--注册中心-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        </dependency>
        <!--日志跟踪-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>
        <!--消息总线-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bus-amqp</artifactId>
        </dependency>
  • 配置
spring:
  application:
    name: ribbon-consumer
  rabbitmq:
    host: ${RABBIT_MQ_HOST:localhost}
    port: ${RABBIT_MQ_PORT:5672}
    username: ${RABBIT_MQ_USERNAME:guest}
    password: ${RABBIT_MQ_PASSWORD:guest}

  zipkin:
    enabled: true
    sender:
      type: rabbit
  sleuth:
    sampler:
      probability: 1.0

scservers(四)服务调用——接口与负载均衡

前言

前面的三篇搭起微服务的基本应用框架:服务发现,分布式动态配置,消息总线的通知能力等。就如人的身体基本上已经有了头脑四肢,基本成形。

头脑四肢之间需要互联互通,相当于服务调用,并且需要一定的协议接口及基于协议的序列化反序列化,比如dubbo,grpc甚至原生的别人不了解的协议等。目前我们这里只介绍下http的,其他基本类同。服务的调用还要负载均衡,不然只用右手,容易起茧。

http-rest

目前http协议所使用的远程调用范式基本以REST为范式,spring3之后就提供RestTemplate来执行rest http接口调用,并提供序列化反序列的能力。但没有负载均衡,负载均衡依赖于服务注册,所以springcloud 提供了Ribbon作为软负载。

而Feign,则是及大成者,包含软件负载(ribbon)的http远程调用及序列化反序列化能力。即有如下方式:

* 原生RestTemplate+Ribbon

* Feign

RestTemplate+Ribbon

  • 配置

    我们需要添加Ribbon的依赖

    <dependency>
        <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
    </dependency>

    但是在示例里面我们并没有在pom.xml中看到这个依赖配置,那是因为我们已经存在如下依赖:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>

    前面我们说过,负载还依赖于服务注册,而如果使用eureka作为服务注册,那么其已经包含了Ribbon的依赖了。如果使用其他服务注册发现中心,如consul、zookeeper、etcd,那就要加上Ribbon的依赖。嗯,全家桶确实名不虚传。

    eureka的配置这里就不再复述了。

  • 使用

    • step1:@LoadBalanced

      在RestTemplate加上注解@LoadBalanced,让RestTemplate支持负载客户端。
    @Configuration
     class MyConfiguration {
    @LoadBalanced
    @Bean
    RestTemplate restTemplate() {
    return new RestTemplate();
    }
    }
    • step2:配置负载模式

      标明Ribbon负载的工作模式,如果是轮训可以跳过这一步(默认支持轮训),如果想该用其他方式按照如下方式。已经实现了随机模式,我们也可以通过重写类支持其他模式。
    @Configuration
    public class RibbonRuleConfiguration {
    @Bean
    public IRule ribbonRule() {
    return new RandomRule();
    }
    }

    在使用到的control或者service加上使用的ribbon客户端的注解:

    @RibbonClient(name = "center-ribbon-Rule",configuration = RibbonRestTemplateConfiguration.class)
    public class AppApplication {
    
    • step3:使用 RestTemplate远程调用
    restTemplate.getForObject("http://serviceid/restpath", String.class);
    

    Eureka根据 spring.application.name 设置 serviceId,我们只要设置serviceid就可以解析出ip:port。

Feign

Feign 通过注解及拦截器让 Java HTTP 客户端编写更方便。支持可插拔编码器和解码器,降低 HTTP API 的复杂度,通过最少的资源和代码来实现和 HTTP API 的连接。通过可定制的解码器和错误处理,可以编写任意的HTTP API。Spring Cloud Feign 封装了 Ribbon 这一组件,所以在使用 Feign 同时还能提供负载均衡的功能,这一切只需要一个 @FeignClient 即可完成。

  • 配置

    新增依赖 spring-cloud-starter-openfeign

    <dependencies>
        <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>
    </dependencies>
  • 使用

    1. feign client 注解引入

      在application引入 feign注解

      @EnableFeignClients
      
    2. feign client 接口

      定义rpc服务的接口

      @FeignClient( name = "center-demo", path = "/test", decode404 = true)
      public interface DemoFeignclient {
      @GetMapping("/config")
      String selectconfigByName(@RequestParam String name);
      }
    3. 调用接口

      在service中实例化该接口并使用

          @Autowired
      private DemoFeignclient feignClient;
      
      @RequestMapping("/test/feign")
      public String testconfigrpcByFeign(String name) {
      return "Feign get username <<==>> "+feignClient.selectconfigByName(name);
      }

      我们看到,所有服务提供者供外部调用的接口是一样的,如果每个不同消费者都些feign client 接口,就做了重复的工作,这就是坏味道,所以我们可以像dubbo一样在写服务提供者的时候,就可以把接口单独整个架包出来,供消费者使用。具体可见后面章节的最佳实践。

  • 拦截器

    上面是使用 Feign 来调用简单的远程服务,但实际上远程服务一般会有权限验证(这部分后续章节也会出),需要在 header 中传递 token之类的。在方法中显示传递又过于麻烦了,这时候就可以考虑使用 Feign 提供的RequestInterceptor 接口,只要实现了该接口,那么Feign每次做远程调用之前都可以被它拦截下来在进行包装。示例如下,就可以方便的传递header字段了。

    @Configuration
    public class FeignInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate requestTemplate) {
    requestTemplate.header("token", "ok");
    }
    }
  • 源码

  • PS注意

    Feign与显示声明的Ribbon不要混合在一个controller下使用,不然使用Feign的时候会间歇性提示404错误

          {"timestamp":"2019-03-21T05:37:41.540+0000","status":404,"error":"Not Found","message":"No message available","path":"/test/token/back"}
    

scservers(三)消息总线bus

前言

消息总线bus作为一个轻量化消息中心,通知订阅的方式,完成消息的传递,其基础的应用就是与配置中心结合,通过bus通知client来配置中心拉去更新配置。

消息总线bus

spring cloud 通过封装消息队列rabbitmq,kaffka提供我们bus的一些基础功能。发送配置更新消息。

rabbitmq

安装好rabbitmq服务端,直接使用docker-compose吧,方便。

客户端client

  • 使用bus只需要pom.xml引入如下架包配置
<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
  • 同时对rabbitmq 的连接信息进行配置:
spring:
  application:
    name: bus-server
  rabbitmq:
    host: ${RABBIT_MQ_HOST:localhost}
    port: ${RABBIT_MQ_PORT:5672}
    username: ${RABBIT_MQ_USERNAME:guest}
    password: ${RABBIT_MQ_PASSWORD:guest}

即与使用其他mq方式无异。

  • 消息队列注册
@Configuration
public class RabbitMQConfig {
    @Bean
    public Queue testhelloQueue() {
        return new Queue("testhello");
    }

}
  • 消息消费
@Component
@RabbitListener(queues = "testhello")
public class ReceiverDefault {
    private final Logger logger = LoggerFactory.getLogger(ReceiverDefault.class);

    @RabbitHandler
    public void receiver(String hello){
        logger.info("接收消息=====》》》》》{}",hello);
    }
}
  • 消息推送
@Component
public class SenderDefault {
    private final Logger logger = LoggerFactory.getLogger(SenderDefault.class);
   
    @Autowired
    private AmqpTemplate amqpTemplate;

    public void sender(String context){
        
        logger.info("发送消息=========》》》》{}",context);
        this.amqpTemplate.convertAndSend("testhello",context);
    }
}

config通知

除了常用的消息队列功能,在微服务的架构中,其与config可以深度结合进行分布式的配置变更的通知。

  • 配置

    配置中心及客户端配置见配置中心一节
  • 流程

    1. 将配置通过git发布
    2. git pull 配置http接口,像配置中心发送通知

      curl -i -X POST http://confighost:port/actuator/bus-refresh
      

      应答:

      HTTP/1.1 204
      Date: Sat, 11 Aug 2018 04:06:35 GMT
      
    3. 源码示例

      center/docker-compose-demo.yaml 文件相关内容

scservers(二) 配置中心

前言

前面介绍了服务注册发现,这个是一个比较核心的功能,还有一个服务治理相关的是配置中心,作为分布式微服务,统一设置更新成千上万的微服务配置,也已经基本成为必选项,即使你的服务没有那么多,但是热更新配置等对生产配置变动的及时更新都有帮助。

配置中心

目前配置中心这一服务比较多,国内外都有比较成熟的经过生产实践的产品,如百度的disconf,携程的apollo,springcloud 也有原生的配置中心config。国内生产用得多的应该是携程的apollo,功能强大。这里就暂时先使用springcoud全家桶,apollo后续再介绍使用。

config



configserver 依托git 完成版本管理,也有本地模式。同时为了及时更新还需要消息总线来支持其及时更新配置。

config使用

  • server

    配置中心可以将服务注册到注册中心,作为服务提供者供其他应用使用。

    1. 使用

      • 新建springboot 工程,添加config starter 傻瓜包:

        <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
      • 在工程启动类添加在工程启动类中,添加注解,启用默认config配置的默认值

        @EnableConfigServer
        
    2. 配置说明

      spring:
      application:
      name: config-server
      cloud:
      config:
      server:
      git:
      uri: https://local/willen/config.git
      searchPaths: /
    3. 示例源码

  • client

  • 5

scservers(一) 注册中心eureka

  • 以前做的项目稳态应用系统一直使用公司研发的一套C++ 的rpc调用框架的esb中间件,加上一些周边插件构成的SOA生态,在此基础上开发业务系统。
  • 后来基于互联网生态的发展壮大,一些创新型的业务我们就使用java开发。并选择了dubbo rpc 框架的作为基础调用。
  • 随后在做一些后台管理应用中接触了springboot 相关内容对java 的配置的简略,约定俗成的规则,真的好用。并想将应用系统框架也升级到springcloud 的生态中去,但是耽搁了下后spring cloud 2都出来了,终于下决心迁移整改。

    # 概要
  • 你们猜对了我们想做微服务,虽然我个人认为soa这样的已经挺好了挺规范,但是趋势还是得推动我们不断学习接受新的技术思想,比如现在都已经出来了servicemesh了,但还是先把微服务搞定吧,虽然我们认为技术细节soa跟微服务差异不大,主要在服务治理上的思想差异吧。
  • 作为这种为应用系统提供框架,提供治理能力的东西,一般需要实现这样的能力:
    1. 技术基础:容器(服务集成),路由,消息通信
    2. 核心功能模块:远程调用模块,服务发现,消息队列,分布式事务
    3. 通用功能模块:对象存储,任务调度等公用的基础工具模块
    4. 服务治理:服务限流降级,分布式配置管理

      # 服务发现

      以前我就说过,原公司自己的rpc的路由,即服务发现基于纯分布式的ospf的路由协议算法+esb总线结合实现,优点是不需要中心统一注册,可以自主发现相邻节点。

      缺点的路由寻址数量有限,需要分中心由一个节点进行截断,即路由网关。同时数据流不能直接发送到目标节点,而需要层层转发(只与相邻节点建立连接),虽然会增加不必要的网络压力,却也可以给分中心的网络隔离提供机会(路由网关可以起到跳板机作用)。这种私有协议基础上的功能在特定场景合适,但是不具有广泛性,社区活跃度,eureka这种基于rest接口的c/s结构的服务注册发现服务:便于管理,易用性,适用性强。

eureka

如上图我们可以看到服务提供方注册到eureka-server上,然后服务消费方通过eureka-client从eureka获取到可用服务,然后就可以进行直接的远程调用了。这就实现了对rpc的路由能力的治理。
如果服务较多,eureka server面临的性能压力也比较大,延时等,但是最主要的还是需要高可用能够提供持续不宕机服务。

eureka使用

  • server

    springcloud基于springboot,其开箱即用的原则让我们不需要过多配置就可以傻瓜式的使用eureka,后续源码解析留待下次。

    这里就简单列出配置与说明:

    1. 使用

      • 新建springboot工程,添加eureka starter 傻瓜架包:
      <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      </dependency>
      <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
      </dependency>
      • 启动类添加注解,表明事eurekaServer应用,并启用eurekaServer默认配置:
      @EnableEurekaServer // 启用 eureka server 相关默认配置 
      
    2. 简易配置说明

      server:
      port: ${EUREKA_PORT:8761}
      eureka:
      # 生产环境中官方是不建议修改默认配置,因为那样会破坏 eureka server 的保护模式
      server:
      # 关闭保护模式(生产环境不建议修改)
      enable-self-preservation: false
      # 清理间隔(默认是60 * 1000 毫秒)(生产环境不建议修改)
      eviction-interval-timer-in-ms: 60000
      # Eureka 拉取服务列表时间(默认:30秒)(生产环境不建议修改)
      remote-region-registry-fetch-interval: 5
      client:
      # eureka server 没必要自己把自己注册上去,所以可以设置成 false
      registerWithEureka: false
      # 是否从Eureka Server上获取注册信息,默认为true,此处建议修改成 false (单机设置的意义不大,如果设置成 true 启动会去抓取一次注册表,获取不到更新缓存就会出错(该错误不影响 eureka 正常使用))
      fetchRegistry: false
      serviceUrl:
      # 默认注册地址 this.serviceUrl.put("defaultZone", "http://localhost:8761/eureka/");
      # 划重点:此处的 defaultZone 千万别写成 default-zone
      defaultZone: http://${EUREKA_ZONE_HOST:localhost}:${EUREKA_ZONE_PORT:8761}/eureka/
      spring:
      application:
      name: eureka-server
    3. 示例源码

  • client

apigateway——Kong介绍(一)

网关

一切网络的流量都需要经过网关,api网关就是所有api请求都需要经过网关。

作用

对api进行一个统一的管理及处理,让业务更加专注于业务。

整合内部接口,统一开放入口:

image——>image

对接不同客户:

image

天然的,我们可以在网关层就处理一些非业务强关联的事务,主要就涉及认证,安全,日志,流控,接口聚合,熔断处理等一系列服务能力。

Kong

kong就是一个基于nginx强力的http接入服务器,使用lua进行插件式高扩展能力,高性能的一个API网关。社区版通过插件方式提供了如下的能力,并可以通过lua编写插件的方式进行扩展:

image

image

安装

百闻不如一见,适用的情况下,我们就用最简便的方式,docker容器进行安装,快速高效,

在一个docker环境电脑中就行安装,步骤:

1.新建docker-compose.yml:内容下
version: &#39;2.2&#39;

services:

  kong-database:
    image: postgres:9.4-alpine
    container_name: kong-database
    environment:
      - POSTGRES_USER=kong
      - POSTGRES_DB=kong
    healthcheck:
      test: &quot;pg_isready -U kong &amp;&amp; psql -d kong -U kong -c \&quot;SELECT 1=1\&quot;&quot;
      interval: 10s
      timeout: 5s
      retries: 5

  kong-migration:
    image: kong:${KONG_VERSION}
    container_name: kong-migration
    depends_on:
      kong-database:
        condition: service_healthy
    environment:
      - KONG_DATABASE=postgres
      - KONG_PG_HOST=kong-database
    command: sh -c &quot;kong migrations up &amp;&amp; touch migrations_run &amp;&amp; sleep 30&quot;
    healthcheck:
      test: &quot;if [[ -f migrations_run ]] ; then exit 0; else exit 1; fi&quot;
      interval: 10s
      timeout: 5s
      retries: 5

  kong:
    image: kong:${KONG_VERSION}
    container_name: kong
    depends_on:
      kong-migration:
        condition: service_healthy
    healthcheck:
      test: &quot;kong health&quot;
      interval: 10s
      timeout: 5s
      retries: 5
    environment:
      - KONG_DATABASE=postgres
      - KONG_PG_HOST=kong-database
      - KONG_ADMIN_LISTEN=0.0.0.0:8001
    ports:
      - 8001:8001
      - 8000:8000

  kong-dashboard:
    image: pgbi/kong-dashboard
    container_name: kong-dashboard
    ports:
      - 8080:8080
    depends_on:
      kong:
        condition: service_healthy
    entrypoint: ./docker/entrypoint.sh start --kong-url http://kong:8001 
2.启动
KONG_VERSION=0.11-alpine  docker-compose -f docker-compose.yml up
3.分析

在这里我们没有进行集群,一共启动三个服务,kong的数据库,kong网关,还有一个kong的管理应用,可以直观的提供web界面浏览kong网关相关信息。我们来看看提供出来的相关参数。

端口

kong:8000业务端口(所有api进此端口),8001管理端口(kong提供了restful管理接口,可对api,插件进行各种管理操作,如新增接口,新增用户等)。

kong的数据库可以使用postgres,也可以使用cassandra。

jenkins持续集成二——spring boot集成设置

前面安装好了环境,这一篇主要讲下设置

系统管理->管理插件

image_thumb9

以下是默认安装插件之外,需要额外安装的插件。

系统管理->全局工具配置

image_thumb4

配置JDK

image_thumb1

配置git

image_thumb3

配置maven

image_thumb7

系统管理->系统设置

image_thumb11

这里主要需要对jenkins 将集成应用通过ssh部署到应用服务器的SSH 连接配置

示例如下,同时需要了解SSH免密登录相关内容。

image_thumb14

SSH免密登录

#ubuntu环境在客户机器上生成密钥对,密钥会生成在~/.ssh/目录下
ssh-keygen -t rsa

生成多机器不同密钥对免密登录配置

#配置多远程机器不同密钥的配置,在~/.ssh/ 生成config
touch config

示例配置如下

image_thumb16

将公钥拷贝到远程机器上

#ssh-copy-id [-i [identity_file]] [user@]machine
ssh-copy-id -i id_rsa_git git@127.0.0.1
#该公钥信息会记录到git 服务器的~/.ssh/authorized_keys 文件

测试

ssh git@git #or ssh git@127.0.0.1

Credentials

从git 拉取代码,使用SSH 信用连接,设置 Credentials,添加git 相关的SSH 连接认证,如下图示例:

image_thumb20

Maven 构建项目配置

新建按钮如下

image_thumb18

配置

git源

image_thumb22

构建触发

image_thumb24

10分钟构建一次

自动部署

image_thumb26

文件存档

image_thumb28

jenkins持续集成(一)-基础安装设置

jenkins  作为持续集成现在用得越来越广,以前都是公司直接配置好了用上就好,现在就按部就班从0开始弄个持续集成环境吧。


jenkins

安装

wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

启动

启动:  
sudo service jenkins start  
停止:  
sudo service jenkins stop

路径

log 路径:/var/log/jenkins/jenkins.log
jenkins的home路径:/var/lib/jenkins
端口号修改路径:sudo vi /etc/default/jenkins

初始化

通过浏览器就可以访问Jenkins了。比如我的地址:http://192.168.2.126:7777/,按照页面提示安装插件及设置管理员账户密码。

image

为了确保Jenkins的安全,将管理员的密码写入文件,需要复制到下面的文本框做验证。

/var/lib/jenkins/secrets/initialAdminPassword

然后,到了选择插件的界面,通过附加功能扩展Jenkins可以支持许多不同的需求。

image

image

image

image

git

安装

安装
sudo apt-get install git
#添加用户
useradd git
#配置SSH登录
cd ~
mkdir .ssh 
cd .ssh
touch authorized_keys
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
rm ~/id_rsa.pub
#授权
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

使用

#新建目录
mkdir   zwr
#新建初始化仓库
git init --bare test.git

Maven

安装

方式一

#下载
wget http://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz
#解压
tar -xzf apache-maven-3.3.9-bin.tar.gz
#移动
mv apache-maven-3.3.9  /usr/share/maven
#设置环境变量
vim /etc/profile
#环境变量内容
M2_HOME=/usr/share/maven
CLASSPATH=$CLASSPATH:$M2_HOME/lib
PATH=$PATH:$M2_HOME/bin
export   PATH    CLASSPATH   M2_HOME
#生效
source /etc/profile

方式二

apt-get install -y maven
mvn -version

如何架构一个新的综合金融交易系统

 

技术产品需求

客户端网站系统(app),业务系统(接口),运维平台

网站系统:

基础系统:

1.用户(帐户)管理系统 2.商品(行情)管理系统 3.订单(交易管理)系统 4.支付系统5.风控系统

增值系统:

客户服务系统,筛选筛选系统,资讯系统。。。

业务系统:

管理系统:

用户管理系统

运营支撑系统

核心系统:

订单交易系统

查询系统

行情系统

增值系统:

数据统计(报表)系统

客户服务系统

 

技术栈选型

1.前端系统

2.后端系统

2.1 负载均衡及http 服务器接入:nginx

2.2 web 应用容器 SOA 服务 Tomcat + dubbo

2.3 文件服务器

        2.3.1 储存方式
        2.3.2 储存容量
        2.3.3 安全性与存取权限控管
        2.3.4 存取效能

2.4 缓存服务器
         2.4.1 分布式Redis缓存
         2.4.2 Memcache缓存

2.5 消息系统
         2.5.1 ActiveMQ
         2.5.2 分布式消息系统Kafka、Rocketmq等

2.6 数据持久层
         2.6.1 关系型数据库
              (1). Mysql

        2.6.2 Nosql
              (1). MongoDB