夜明的孤行灯

月度归档： 2018 年 8 月

  • Docker化CAT监控系统

    CAT是点评开源的监控系统，可以统计到粒度非常细，而且也支持hadoop，可以应对企业应用。

    CAT底层使用的是MySQL，需要预先初始化数据库，而且还附带了几个配置文件，总之并不是一个war包就可以启动的。

    为了本地快速调试和集成，还是Docker化一下吧。为了简单起见就只准备一个单机模式的镜像。

    首先是准备几个xml文件，因为是单机模式，就全部只想要127.0.0.1了。

    <?xml version="1.0" encoding="utf-8"?>

<config mode="client" xmlns:xsi="http://www.w3.org/2001/XMLSchema" xsi:noNamespaceSchemaLocation="config.xsd" xmlns="">
    <servers>
        <server ip="127.0.0.1" port="2280" http-port="8080"/>
    </servers>
</config>
    <?xml version="1.0" encoding="utf-8"?>

<config local-mode="false" hdfs-machine="false" job-machine="true" alert-machine="false">

    <storage local-base-dir="/data/appdatas/cat/bucket/" max-hdfs-storage-time="15" local-report-storage-time="7"
             local-logivew-storage-time="7">
    </storage>

    <console default-domain="Cat" show-cat-domain="true">
        <remote-servers>127.0.0.1:8080</remote-servers>
    </console>
</config>

    最关键的就是数据库的准备了，CAT仓库准备了一个SQL文件。我的操作是在连接数据库的时候先检查数据库是否有表，没有就先建表。之后再替换datasource配置中的文件信息…

  • DataGrip的自动代码生成

    DataGrip的自动代码生成

    DataGrip

    DataGrip是一款数据库客户端工具，是大名鼎鼎的JetBrains公司出品的，相信大部分程序员都用过同公司的Intellij IDEA。

    DataGrip可以连接到数据库服务器，执行sql、管理表（创建表，修改索引等等）以及导出数据等。之前一直用的免费的MySQL Workbench，这个工具是免费的，能够满足日常需求，但是在Mac上经常死机，还有就是自动感应不是很灵敏。另外一个缺陷是专为MySQL设计。

    想着因为是Apache committer的原因Jetbrains的全线产品免费，就尝试了一下DataGrip。

    DataGrip和Intellij IDEA是一个壳子的，所以从样式，布局都是一样的，熟悉感很重，特别是两个软件切换来切换去的时候特别容易搞混。

    DataGrip对于数据库的支持很宽泛，从PostgreSQL到MySQL再到Oracle这些都支持（其实我平时只用到了MySQL）。虽然官方没有说支持Hive数据库，但是实际上可以自定义driver和datasource，也可以用。

    代码自动生成

    这里的代码自动生成就是指数据库相关的Java代码或者MyBatis mapper可以自动生成。

    代码自动生成对于效率的提升是很大的，不光是时间上的节约，还有一些就是代码准确度的提升。从纯工程实践的角度讲，给予成熟模版生成的代码绝对是一个很划算的买卖。特别对于一些完全没有技术含量的活，代码自动生成尤为重要。

    现在很多代码自动生成都是基于Velocity 模板引擎来做的，也就是说代码的情况完全看模版，如果有需要可以修改模版（前提是工具或者扩展允许修改）。

    Mybatis自带生成器，也有maven插件，但是灵活性一般，而且配置比较繁琐。

    DataGrip的脚本扩展

    DataGrip在2017.01版开始提供脚本扩展，支持groovy和cli。用法很直接，选中一个表，右键执行对应的脚本就行了。

    网上能找到一些脚本，但是更多时候需要自己修改以符合公司内部规范或者项目组的一般规范，不过脚本扩展的优势就是比较容易修改，不过可读性其实比不过模板生成的模式。

    DataGrip自带了一个生成Pojo的groovy脚本，可以直接用，不过那个脚本不会自动添加注释，自己稍加修改就好了。

    脚本扩展的例子

    import com.intellij.database.model.DasTable
import com.intellij.database.model.ObjectKind
import com.intellij.database.util.Case
import com.intellij.database.util.DasUtil

/*
 * Available context bindings:
 *   SELECTION   Iterable<DasObject>
 *   PROJECT
    …

  • 本地搭建hive集群

    最近有一些hive相关的工作，之前只用过简单的hive，现在只有赶快补一下。

    本地还是用docker启一个hive集群，我直接用的https://github.com/big-data-europe/docker-hive.git 的脚本，clone下来以后直接docker-compose up -d

    查看8080端口可以看到集群状态

    数据库端口在10000上。

    这里我用DBVisualizer来连接一下。

    先下载Hive Driver

    然后添加连接hive://localhost:10000

     …

  • 使用Docker快速启动一个Spark集群

    docker-compose 文件如下

    version: '3'
services:
  master:
    image: bde2020/spark-master:2.3.1-hadoop2.7
    ports:
      - "8080:8080"
      - "7077:7077"
      - "6066:6066"
    environment:
      - INIT_DAEMON_STEP=setup_spark
  worker:
    image: bde2020/spark-worker:2.3.1-hadoop2.7
    depends_on:
      - master
    ports:
      - "8081"
    environment:
      - "SPARK_MASTER=spark://master:7077"

     

    然后运行docker-compose up -d –scale worker=3　就可以启动一个有三个节点的集群了．…

  • 细说降级

    什么是降级

    当出现大流量或者其他情况时我们需要保护我们的系统，这里有三大利器：缓存、降级和限流。

    降级是一种利用有限资源，保障系统核心功能高可用、有损的架构方法。降级的最终目的是保证核心服务可用，即使是有损的，同时有些服务是无法降级的。

    实施降级

    实施降级需要综合分析系统情况和业务情况，要判断是否可以“丢卒保帅”，同时梳理出核心链路，保护核心业务。

    考虑到影响业务的范围降级可以分为以下几种：

    页面降级

    在特殊情况下（一般是热门活动），有些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，页面暂时无法访问。

    页面片段降级

    比如商品页面中包含其他商品推荐信息，这个片段可以暂时屏蔽。

    页面异步请求降级

    比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级

    服务功能降级

    比如渲染商品详情页时需要调用一些不太重要的服务，比如外卖中的骑手配送路径，紧急情况下可以不显示路径，只显示配送时间和状态。

    读降级

    比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；

    写降级

    特殊情况下如果可以接收最终一致性，可以直接写cache，用于缓解数据库的压力，比如秒杀。

    降级预案

    一般情况下降级的发生是可以预期的，比如相关业务促销，或者新业务进入新城市的时候。这个时候预案是最重要的，首先再次明确核心链路是什么，哪些不能超时，不能不可用，哪些可以接收一定超时，不能不可用，哪些可以超时，可以不可用。

    我们假象一个微信公众号点餐系统，比如下图

    很容易梳理出来查看菜品，余额和消费付款都是核心，会直接影响交易本身。而会员信息修改，发放优惠券就是暂时不可用的，而菜品评价是可以部分可用或者接收一定的超时的。

    梳理出这些内容以后，那么就需要明确降级开关的触发条件和方式，这个是业务和技术的综合问题，同时要明确降级触发以后的需要周知的干系人。

    自动降级

    监控对于系统的健康必不可少，监控可以覆盖很多方面，比如流量，JVM，日志等等。而自动降级是一个很吸引人的东西，它是根据系统负载、资源使用情况、SLA等指标自主进行降级。

    超时降级

    当访问的数据库或者rpc调用超过默认设定值以后，若服务不是核心服务的话可以在超时后自动降级；具体的服务响应最大时间需要和服务提供方商议，或者根据监控系统的历史数据来评估。

    失败次数降级

    有时候依赖一些不稳定的API，比如调用第三方商家系统，当失败调用次数达到一定阀值后自动降级；然后通过异步线程去探测服务是否恢复了，则取消降级。

    这个有点类似半开式熔断。

    故障降级

    比如要调用的远程服务挂掉了比如Dns故障，则可以直接降级。降级后的处理方案有：兜底数据、缓存或者默认值。

    限流降级

    当我们去秒杀或者抢购一些限购商品时（比如小米抢购…），此时可能会因为访问量太大而导致系统崩溃，可以用限流来限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面。

    参考

    http://jinnianshilongnian.iteye.com/blog/2306477…