linux 上一些软件包的安装，往往需要很多手工介入的安装步骤，不利于进行大规模集群部署，而且免不了对一些软件需要定制化改造的需求，需要源码安装。如果需要一台台地去编译安装，那么运维就不用出机房了

文章以mysql打包构建为例，实现 基于源码构建定制化rpm包 和基于 二进制安装包构建rpm包 两种方式的的打包

打包好了，将该rpm包发布到构建的本地yum源，集群中所有机器一个yum install 命令就可以搞定了。如何在本地搭建yum源，可以见上一篇文章：自动化部署 - 构建YUM本地源

yum 本地源 构建

学会打rpm包后（见如何利用rpm-maven-plugin打包前后端项目，那么接着就是在本地集群构建yum源了

文章包含两个部分：一是自动脚本构建 yum源，二是分发yum源配置，使得整个集群yum安装从本地源拉取

相比较而言，本地YUM源服务器最大优点在局域网的快速网络连接和稳定性。有了局域网中的YUM源服务器，即便在Internet连接中断的情况下，也不会影响其他YUM客户端的软件升级和安装

构建本地yum源适用于以下场景：

• 客户现场没有网络环境
• 外网环境不佳
• 减轻带宽压力
• 本地化自动部署

本地源配置的三种方式

• 一是直接使用CentOS光盘作为本地yum源，优点是简单便捷，缺点是光盘软件包可能不完整(centos 7 Everything 总共才6.57G)；
• 二是同步CentOS官方源到本地（相当于创建了一个公共镜像），优点是最靠谱，缺点是占空间费流量；
• 三是创建完全自定义的本地源，优点是灵活性最大，缺点是只是作为其他源的补充。

因为有本地化部署的需求，且客户现场没有网络环境，所以稍微了解和构建下 CentOS光盘和 自定义本地源两种方式，最后通过构建脚本自动构建yum本地源，且通过分发脚本将yum源配置同步到集群的各台机器

原理 从服务器A登录到服务器B，借用网上的一张图片

图片来源

具体的操作：
A上面生成私钥公钥对，拷贝公钥内容追加写入到B的授权文件/root/.ssh/authorized_keys。

上面的是单机操作，如果应对到几台/几十台的集群配置，手动去配置，那么需要配置n x 3次，这酸爽，手动表情[哭笑不得]

以下通过一个shell脚本，自动生成各台机器的id_rsa密钥对，并将所有机器的公钥写入到文件中，再自动将该文件内容分发到所有服务器并且将文件内容追加写入到authorized_keys文件

Maven打包成RPM

RPM全称是 Red Hat Package Manager（Red Hat包管理器）。几乎所有的 Linux 发行版本都使用这种形式的软件包管理安装、更新和卸载软件。

在devops链条上，常见的部署方式是通过持续集成工具如jenkins/CI 构建和发布jar包到服务端制定目录。不过随着越来越多的应用趋向于paas 平台，本地化自动部署的需求越来越多，在软件包的安装过程中各种自动控制命令的集成也越来越复杂，jenkins等部署方式已经无法满足需求，这时候将软件包和集成脚本一起打包成rpm包的形式，也是一种另外的思路。对于最终用户来说，使用 RPM所提供的功能来维护系统是比较容易和轻松的。安装、卸载和升级RPM软件包只需一条命令就能搞定。
后续还可以构建yum本地源，通过ambari等其他集成工具，进行对软件包的安装、管理、监控、卸载、升级全生命周期的管控

利用rpm-maven-plugin插件实现rpm构建，以便于RPM软件仓库管理。
包含四个部分：

• 基本单项目 打包成rpm
• 多module 项目打包成rpm
• 纯前端项目 打包成rpm
• rpm script 应用-通过自动创建软连接实现rpm包自动升级

备注：

rpm-maven-plugin 需要在linux 机器上才能正常运行，运行机器需要

1

yum install rpm-build

基于spring boot的一个小项目，前后端分离，采用REST风格的接口设计，在做权限设计时觉得以前的权限控制实现比较繁琐，一个Action就对应一条Permission。所以想着接口可以走REST风格，权限为什么不可以呢？比如称作READ风格的权限控制(Representational Authorization Design)……

REST早已不是新鲜事物，基于REST的权限控制网上也是有现成的，基于RESTful API 怎么设计用户权限控制？写得很棒，所以基于这篇文章的设计思路做了个实现(java)。本文的前半段，主要是引用文章阐述设计思路，后半部分主要为程序code实现。

其中后端自定义一个过滤器做权限过滤，用到了spring util包下的AntPathMatcher做权限规则匹配；前端也就一个directive就搞定了。技术上并没有引用什么技术框架，关键还是抽象思维且将设计思路转化为程序上code。

传统的权限配置 vs 权限被抽象成资源和状态

1
2
3
4
5

/getUsersGroups?id=1
/getUsersExpress
/getUsersLables?eventId=xxx
/createUsers?name=xxx&age=18
/updateEvent?id=xx

vs

1
2
3

GET /users/**  表示 对 users 资源 及events 附属的资源 有获取/浏览的权限
POST /users    表示 对 users 资源 有新增的权限
PUT /users/*   表示 对 users 有 修改的权限

spring boot 动态数据源配置 & 运行时新增数据源

场景：

1. 同一系统支持不同业务场景，需要用到不同的数据库。
2. 各个用户/应用之间数据完全隔离(不同的用户/应用，不同的数据库），而一个程序需要支持不同的用户/应用。例如 一些paas服务需要支持不同的业务场景，但是不同项目之间数据、账号、权限、token等业务数据都是完全隔离的，仅共享机器资源。

一、spring boot 动态数据源配置

方案：在一个确切的地方存储 数据源的配置信息（我是将这些信息存储在一个 配置数据库表中，而这个配置数据库是确切的，作为主数据源配置）。启动spring时，会初始化这个配置数据源，然后将其他动态数据源信息取出来初始化好datasource 注册到spring 容器。

原理：主要是实现AbstractRoutingDataSource的抽象类，然后将该类注册到spring容器，其中关键点是：

1. 配置AbstractRoutingDataSource类的默认数据源Object defaultTargetDataSource 和其他数据源Map<Object, Object> targetDataSources。targetDataSources就是我们动态配置的数据源，key-value 接口，后面根据key 查找 datasource
2. 实现determineCurrentLookupKey()方法，该方法决定了当前操作选择哪个数据源
3. 注册到spring 容器

转化漏斗的基本实现

参照 clickhouse-presentation funnel 实现：
https://github.com/yandex/clickhouse-presentations/blob/master/meetup9/funnels.pdf

测试环境：单机 Intel Xeon L5520,内存16G（配置是不是很穷呢😭）
样本数据：易观OLAP大赛Demo数据,官方说6亿，17年1月和2月的数据，我实际下载数据总条数3亿左右，只有1月的数据，可能下载过程丢了。。。

测试项

• 计算2017年1月份中，依次有序触发“搜索商品”、“查看商品”、“生成订单”的用户转化情况，且时间窗口为1天。
• 计算2017年1月和2月份中，依次有序触发“登陆”、“搜索商品”、“查看商品”、“生成订单”、“订单付款”的用户转化情况， 且时间窗口为7天，“搜索商品”事件的content属性为Apple，“浏览商品”事件的price属性大于5000。

原题中，有时间窗口概念，clickhouse现有原生聚合函数无法支持，所以到后面实现；下载的数据没有二月份的，而且机器配置有点低，测试的时候好几次内存不够分配

Clickhouse tutorial

ClickHouse is an open source column-oriented database management system capable of real time generation of analytical data reports using SQL queries.

参照官网教程:https://clickhouse.yandex/tutorial.html

单节点，测试数据为 1987到2015 美国民用航班数据，1.66亿rows

• single server
• use USA civil flights data since 1987 till 2015
• contains 166 millions rows, 63 Gb of uncompressed data

我的测试基于 centos6.9

其他系统安装见：official Docker images of ClickHouse