本文最初发表于 RedHat的开发者博客，经RedHat和原作者Juraci Paixão Kröhling授权由InfoQ中文站翻译分享。

入门分布式跟踪可能是一项很艰难的任务。这个领域有太多新术语、框架和工具，它们有着明显互相重叠的功能，初学者很容易迷失或偏离主题。本文对最流行的工具进行了概述和分类，能够帮助你掌握分布式跟踪领域的概况。

虽然跟踪和采样分析是密切相关的两个学科，但是分布式跟踪通常被理解将应用中不同工作单元的信息连接在一起，以便理解整个事件链的技术，这些工作单元会在不同的进程或主机中执行。在现代应用程序中，这意味着分布式跟踪可以用来描述HTTP请求在穿越 大量微服务时的情况。

这里所列的大多数工具可以大致分为instrumentation库、tracer、分析工具（analysis tool，后端+UI），以及它们的任意组合。博文“ 各种跟踪方式的差异”很好地描述了分布式跟踪的这三个方面。

对于本文来讲，我们将 instrumentation定义为用来告诉记录哪些信息的库，将 tracer定义为如何记录并提交数据的库，将 分析工具定义为接收跟踪信息的后端。在现实中，这些分类是不断变化的，instrumentation和tracer的区别并不会始终那么明显。类似的，分析工具这个术语可能会过于宽泛，因为有些工具会关注探索跟踪信息，而有些则是完整的可观察性平台。

　　谷歌在其开源博客中宣布开源 Android语音识别转录工具——Live Transcribe的语音引擎，它可以将语音或对话实时转录为文字，还能够为听障人士提供帮助。

　　Live Transcribe 是谷歌于今年2月推出的一款Android应用程序，它的语音识别由谷歌最先进的Cloud Speech API提供。但是，依赖于云引入了一些复杂性，不断变化的网络连接、数据成本和延迟等等都带来一些考验。因此，谷歌把它开源出来，希望开发人员在已有的基础上进一步构建和开发。

　　Cloud Speech API目前无法支持无限的音频流，团队采取了一些措施来解决这一难题，例如在达到超时之前关闭并重新启动流式传输请求，这将有效减少会话中丢失的文本量。

　　值得一提的是，Live Transcribe支持超过70种语言，并能够根据语音自动识别语种，其中也包括中文。

　　另外，由于是提供实时语音转录，转录出来的文本会随着语音的输入不断发生变化，降低延迟自然十分必要。该引擎能够大大降低延迟率，这都要归功于它的自定义Opus编码器。

　　 Live Transcribe语音引擎功能

　　Google列出了语音引擎的以下功能（不包括说话人识别）：

　　无限流媒体。

　　支持70多种语言。

　　可以简化网络丢失（在网络和Wi-Fi之间切换时）。文字不会丢失，只会延迟。

　　强大的扩展网络损耗。即使网络已经停电数小时，也会重新连接。当然，没有连接就不能进行语音识别。

　　可以轻松启用和配置Opus，AMR-WB和FLAC编码。

　　包含文本格式库，用于可视化ASR置信度、发言人ID等。

　　可离线模型扩展。

　　内置支持语音检测器，可在延长静音期间用于停止ASR，以节省资金和数据。

　　内置支持扬声器识别，可根据扬声器编号标记或着色文本。

　　英文原文： Bringing Live Transcribe's Speech Engine to Everyone

前言

最近个人事情比较多（搬家、换工作、短暂休息）所以一直也没有顾得上博客更新，恰好最近收到一封邮件提醒了我。

也是时候写一篇文章来聊聊参与开源项目的事（最近也确实进入了笔荒期）。

ps:第一次收到这样的中秋节礼物，加上 Dubbo社区的活跃及阿里的重视度，还在做 PRC或微服务技术选型的朋友可以考虑 Dubbo。

参与开源

现在具体来聊聊参与开源的事；

日常几乎所有的开发者都会享受到开源项目所带来的便利甚至是收益，受限于环境早在十几年前甚至几年前开源活动一直都是有国外开发者主导。

但这几年国内互联网公司逐渐国际化扩大影响力也很大程度的提高了我们的开发水平，以 BAT为首出现了许多优秀的开源项目。

现在甚至参与开源项目还能另辟蹊径的拿到大厂 offer，所以其实不少朋友都想参与其中，可能这事给人的第一感觉就不太容易，所以现在还卡在第一步。

具体步骤

以下是以我个人经验总结的几大步骤：

• 发现问题或自荐 feature。
• fork 源码。
• 本地开发、自测。
• 发起 pull request。
• 等待社区 Code Review。
• 跟进社区意见调整代码。
• 审核通过，合并进 master分支，完成本次贡献。

下面我会结合最近一次参与 Dubbo的流程来具体聊聊。

发现问题或自荐 feature

首先第一步自然要搞清楚自己本次贡献的内容是什么？通常都是解决某个问题或者是提交一个新的 feature；前者相对起来更加容易一些。

当然这个问题可以是自己使用过程中发现的，也可以是 Issues 列表中待解决的问题。

以本次为例，就是我在使用过程中所发现的问题，也提交了相关 Issue并写了一篇文章记录并解决了该问题： What？一个 Dubbo 服务启动要两个小时！

值得注意的是在提交 Issue 之前最好是先在 Issue 列表中通过关键字检索下是否已经有相关问题，避免重复。

同时提交之后也许社区会进行跟进，被打上 invalid标签认为不是问题，或者是使用姿势不对也是有可能的。

fork 源码，本地开发

当确定这是一个待修复的问题时就可以着手开发了。

首先第一步自然是将源码拷贝一份到自己仓库中。

接着只需要 clone 自己仓库中的源码到本地进行开发。

先回顾下我遇到的这个问题。

简单来说就是启动 Dubbo服务非常缓慢，经过定位是 main线程阻塞在了获取本机 ip 处。

所以当时我提出的方案是：在获取本机 ip 时加上超时时间，一旦超时便抛出异常或者是再次重试，但起码得有日志方便用户定位问题。

问题是主线程会一直阻塞在此处 InetAddress.getLocalHost().getHostAddress()，但又需要知道它阻塞了多久才好判断是否超时。

所以只能再额外开启一个线程，定时去检测 main线程是否已经完成任务了，以下便是我第一次 pr 的内容。

这次的重点不是讨论这里具体的技术细节，所以简单说下步骤：

• 额为声明了大小为 1 的线程池。
• 再声明了一个 volatile标志用于判断主线程是否有完成任务。
• 声明了一个 condition 用于新线程做等待。
• 最后只需要运行这个线程用于判断这个标志即可。

如何自测

开发完成后下一步就是自测，由于这类项目是作为一个基础包依赖于其他的项目才能运行的，所以通常我们还得新建一个项目来配合做全流程测试（单测除外）。

这里我觉得还是有几个小技巧值得注意。

第一个是版本号；因为在本地测试，所以需要使用 mvn clean install将包安装到本地才能在其他项目中依赖进去进行测试。

但由于我们从官方拉出来的代码版本都已经发布到了 maven 中央仓库中（不管是 release 还是 snapshot），所以我们本地仓库中肯定已经存在这几个版本的 jar 包。

一旦我们执行 mvn clean install将自己修改的代码安装到本地时，大概率是会出问题的（也可能是我姿势不对），这样就会导致新建的项目中依赖不了自己新增的代码。

所以我通常的做法是修改版本号，这个版本号是从来没有被官方发布到中央仓库中的，可以确保自己新增的代码会以一个全新版本安装到本地，这样我们再依赖这个版本进行测试即可。

不过再提交时得注意不要把这个版本号提交上去了。

发起 pull request

自测完成后便可发起 pull request了，不要大意，这里还得有一个地方需要注意，那就是代码换行符的问题。

一旦换行符与源仓库的不一致时， git会认为这次修改是删除后重来的，这样会给 code review带来巨大的麻烦。

就像这样，明明我改动的行数并不多，但 git确认为你是推翻了重来，导致审核起来根本不知道你改了哪些地方。

最简单的方法就是设置自己 git的全局配置，可以参考 这里。

1
2
3
4
5
6
7
8

# 提交时转换为LF，检出时转换为CRLF
git config --global core.autocrlf true
# 提交时转换为LF，检出时不转换
git config --global core.autocrlf input
# 提交检出均不转换
git config --global core.autocrlf false

确认没问题后便可点击这里发起 pull request，后面按照引导执行即可。

当然各个项目之间还会有自己定制的贡献流程，最好就是查看官方的贡献指南。

http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html

Code Review

pr发起后便可等待社区审核了。

在这过程中要充分和社区进行交流，有可能你的方案和社区的想法并不一致。

比如像我这次：

最终通过沟通加上自己后面的思考觉得还是社区的方案更加轻便合理一些，达成一致之后社区便将这次 pr 合并进 master 中。

其实整个过程我觉得最有意义的便是 code review的过程，所有人都可以参与其中头脑风暴，其中也不乏技术大牛，不知不觉便能学到不少东西。

类似案例

虽然我之前的方案没有被采纳，但类似的用法（一个线程监控其他线程）还是不少，正好在 Dubbo中也有用到。

便是其中核心的服务调用，默认情况下对使用者来说这看起来是一个同步调用，也就是说消费方会等待 PRC 执行完毕后才会执行后续逻辑。

但其实在底层这就是一个 TCP网络包的发送过程， 本身就是异步的。

只是 Dubbo在你不知道的情况下做了异步转同步，这样看起来就像是一个同步方法。

如图中的红框部分， Dubbo自身调用了 get()方法用于同步获取服务提供者的返回结果。

逻辑其实也挺简单，和我上文的方案类似，只是这里的 isDone()函数返回的是是否已经拿到了服务提供者的返回值而已。

总结

本次总结了参与开源的具体步骤，其实也挺简单；就如官方所说哪怕是提个 Issue，修改一个错别字都算是参与，所以不要想的太难。

最后还简单分析了 Dubbo 调用过程中的异步转同步的过程，掌握这些操作对自己平时开发也是很有帮助的。

你的点赞与分享是对我最大的支持

一、ModSecurity3.0介绍

ModSecurity是一个开源的跨平台Web应用程序防火墙（WAF）引擎，用于Apache，IIS和Nginx，由Trustwave的SpiderLabs开发。作为WAF产品，ModSecurity专门关注HTTP流量，当发出HTTP请求时，ModSecurity检查请求的所有部分，如果请求是恶意的，它会被阻止和记录。

优势：

完美兼容nginx，是nginx官方推荐的WAF

支持OWASP规则

3.0版本比老版本更新更快，更加稳定，并且得到了nginx、Inc和Trustwave等团队的积极支持

免费

ModSecurity的功能：

SQL Injection (SQLi)：阻止SQL注入

Cross Site Scripting (XSS)：阻止跨站脚本攻击

Local File Inclusion (LFI)：阻止利用本地文件包含漏洞进行攻击

Remote File Inclusione(RFI)：阻止利用远程文件包含漏洞进行攻击

Remote Code Execution (RCE)：阻止利用远程命令执行漏洞进行攻击

PHP Code Injectiod：阻止PHP代码注入

HTTP Protocol Violations：阻止违反HTTP协议的恶意访问

HTTPoxy：阻止利用远程代理感染漏洞进行攻击

Shellshock：阻止利用Shellshock漏洞进行攻击

Session Fixation：阻止利用Session会话ID不变的漏洞进行攻击

Scanner Detection：阻止黑客扫描网站

Metadata/Error Leakages：阻止源代码/错误信息泄露

Project Honey Pot Blacklist：蜜罐项目黑名单

GeoIP Country Blocking：根据判断IP地址归属地来进行IP阻断

劣势：

不支持检查响应体的规则，如果配置中包含这些规则，则会被忽略，nginx的的sub_filter指令可以用来检查状语从句：重写响应数据，OWASP中相关规则是95X。

不支持OWASP核心规则集DDoS规则REQUEST-912-DOS- PROTECTION.conf,nginx本身支持配置DDoS限制

不支持在审计日志中包含请求和响应主体

二、安装部署

测试环境：centOS7.6阿里云镜像

升级软件和内核

yum update

安装nginx： http://nginx.org/en/linux_packages.html#mainline

yum install yum-utils
vim /etc/yum.repos.d/nginx.repo
[nginx-stable]
name=nginx stable repo
baseurl=    http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=    https://nginx.org/keys/nginx_signing.key
[nginx-mainline]
name=nginx mainline repo
baseurl=    http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=    https://nginx.org/keys/nginx_signing.key
yum install nginx
yum install epel-release
yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre pcre-devel libxml2 libxml2-devel autoconf automake lmdb-devel ssdeep-devel ssdeep-libs lua-devel libmaxminddb-devel git apt-utils autoconf automake build-essential git libcurl4-openssl-dev libgeoip-dev liblmdb-dev ibpcre++-dev libtool libxml2-dev libyajl-dev pkgconf wget zlib1g-dev

报错解决：Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again

解决办法：一句话：把/etc/yum.repos.d/epel.repo，文件第3行注释去掉，把第四行注释掉，修改为

1. [epel]

2. name=Extra Packages for Enterprise Linux 6 – $basearch

3. baseurl= http://download.fedoraproject.org/pub/epel/6/$basearch

4. #mirrorlist= https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

克隆GitHub存储库:

git clone --depth 1 -b v3/master --single-branch    https://github.com/SpiderLabs/ModSecurity

编译源代码：

$ cd ModSecurity
$ git submodule init
$ git submodule update
$ ./build.sh
$ ./configure
$ make
$ make install

注意：安装中有报错fatal: No names found, cannot describe anything.是正常现象

下载用于ModSecurity的NGINX连接器：

git clone --depth 1    https://github.com/SpiderLabs/ModSecurity-nginx.git

确定哪个版本的NGINX是运行在主机上的ModSecurity模块将加载:

[root@guigu ModSecurity]# nginx -v
nginx version: nginx/1.17.3

下载与安装版本对应的源代码：

wget     http://nginx.org/download/nginx-1.17.3.tar.gz
tar zxvf nginx-1.17.3.tar.gz

编译动态模块，复制到模块标准目录:

cd nginx-1.17.3
#./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
$ make modules
cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/
将以下load_module指令添加到/etc/nginx/nginx.conf的main中：
load_module modules/ngx_http_modsecurity_module.so;

确定nginx模块加载成功：

nginx -t

三、防护效果测试

ModSecurity 3简单示例

创建Demo web应用vim /etc/nginx/nginx.conf

server {
listen 8085;    

location / {

    default_type text/plain;

    return 200 "Thank you for requesting ${request_uri}\n";

    }
}

重新加载nginx:nginx -s reload

确认nginx正常工作:curl -D – http://localhost

保护Demo web应用

创建/etc/nginx/modsec文件夹：mkdir /etc/nginx/modsec

下载推荐的ModSecurity配置文件

wget     https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
mv modsecurity.conf-recommended modsecurity.conf

vim modsecurity.conf #在些文件中编辑以下配置

SecRuleEngine DetectionOnly

SecRuleEngine On

创建ModSecurity的主配置文件

vim /etc/nginx/modsec/main.conf

Include the recommended configuration

Include /etc/nginx/modsec/modsecurity.conf

A test rule

SecRule ARGS:testparam "@contains test" "id:1234,deny,log,status:403"

报错解决：[emerg] “modsecurity_rules_file” directive Rules error.

vim /etc/nginx/modsec/modsecurity.conf
#SecUnicodeMapFile unicode.mapping 20127

配置nginx反向代理，vim /etc/nginx/conf.d/proxy.conf

#include /etc/nginx/conf.d/*.conf; #把这一行注释掉，不然80端口会有冲突

server {
    listen 80;    

    modsecurity on;

    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {

    proxy_pass [http://0.0.0.0:8085;](http://0.0.0.0:8085/)

    proxy_set_header Host $host;

    }

nginx -s reload    #重新加载nginx
curl -D -     http://localhost/foo?testparam=123    #能正常返回“Thank you for requesting /foo?testparam=123”
curl -D -     http://localhost/foo?testparam=test    #则返回"403 Forbidden"，说明前面配置的那条modsecuriy规则生效了，并阻拦了testparam参数中带test的请求

在/var/log/nginx/error.log中可以看到拦截的详细日志

部署OWASP规则–CRS（Core Rule Set）

安装运行nikto漏洞扫描工具，用于测试CRS的防御效果

git clone     https://github.com/sullo/nikto    #下载nikto
cd nikto 
perl program/nikto.pl -h localhost    #用nikto扫描nginx搭建的web系统（反向代理）
扫描结果是+ 7687 requests: 0 error(s) and 308 item(s) reported on remote host    #扫描出308个问题

启用OWASP CRS

cd /etc/nginx/modsec/
wget     https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.2.tar.gz    #下载OWASP CRS
cd owasp-modsecurity-crs-3.0.2/
cp crs-setup.conf.example crs-setup.conf

在modsecurity主配置文件中include CRS的配置和规则

vim /etc/nginx/modsec/main.conf

Include the recommended configuration

Include /etc/nginx/modsec/modsecurity.conf

OWASP CRS v3 rules

Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/*.conf

测试CRS

nginx -s reload    #重新加载nginx配置
curl     http://localhost    #返回Thank you for requesting /
curl -H "User-Agent: Nikto"     http://localhost    #返回403 Forbidden，说明WAF防护已经生效，此处匹配的规则是user-agent中不能包含漏洞扫描器名字
perl nikto/program/nikto.pl -h localhost    #再次用nikto扫描nginx搭建的web系统
扫描结果是+ 7687 requests: 0 error(s) and 83 item(s) reported on remote host    #扫描出83个问题，比308个少了很多

在安装ModSecurity时，我们将演示应用程序配置为为每个请求返回状态代码200,但实际上并没有返回这些文件,Nikto将这200个状态码解释为它请求的文件确实存在,所以报告出83个问题，为了优化nikto，去除误报，我们做如下配置

cp nikto/program/nikto.conf.default nikto/program/nikto.conf

vim nikto/program/nikto.conf #在第76行最后加上;-sitefiles，如下所示

@@DEFAULT=@@ALL;-@@EXTRAS;tests(report:500);-sitefiles

之后再次用nikto扫描

perl program/nikto.pl -h localhost

扫描结果是+ 7583 requests: 0 error(s) and 7 item(s) reported on remote host

可以看出问题只有7个问题，由于ModSecurity不支持响应（response）的检查，所以涉及此类的漏洞无法防御。但总体还是抵御了绝大部分的nikto的漏洞扫描。

参考链接：

https://www.nginx.com/resources/library/modsecurity-3-nginx-quick-start-guide/

https://github.com/SpiderLabs/ModSecurity

https://github.com/SpiderLabs/ModSecurity/tree/v3/master

*本文作者：owensky，转载请注明来自FreeBuf.COM

作者：Dan Meyer

译者：罗广明

审校：马若飞

编者按

2019年9月10日，Kong正式宣布开源一款Service Mesh：Kuma。此消息一出，立即在云原生社区引起反响，各大媒体争相报道。让我们跟随SDxCentral的总编辑，一起来看看Kong的CTO如何介绍Kuma这款Service Mesh产品以及对于SMI的看法。关于Kuma的具体功能介绍可以阅读官网博客以及Github。

翻译一下其Github关于Kuma功能特性的简介如下，方便读者了解：

• 通用的控制平面: 易于使用，分布式，可以在任何平台运行。

• 轻量的数据平面: 基于Envoy，可处理任意类型流量。

• 自动化: 在K8s平台上部署无需任何代码改动，也可在虚拟机上灵活部署。

• 多租户: 可在一个集群与同一个控制平面上部署多套服务网格。

• 网络安全: 自动mTLS加密。

• 流量分割: 灵活的ACL规则。

• 流量追踪: 与Zipkin和Jaeger自动集成。

• 流量指标: 与Prometheus/Splunk/ELK自动集成。

• 代理配置模版: 方便进阶(收费)用户配置Envoy。

• 标签选择器: 可应用不同地域的、特定于云的和面向团队的策略。

• 平台中立: 支持K8s, 虚拟机和裸机。

• 强大的APIM Ingress: 与Kong网关集成。

简介

Kong正在将其服务网格平台Kuma打造成一个日益复杂的生态系统，在过去几个月里，许多新加入者和选择涌现出来。

该公司声称Kuma是“一个通用的服务网格”。Kong CTO和联合创始人Marco Palladino解释说，这意味着Kuma不同于市场上的大多数服务网格项目，它的设计初衷是在Kubernetes生态系统内部和外部都能工作，这包括虚拟机(VMs)、容器、legacy环境以及Kubernetes。

Kuma包括一个基于Envoy服务代理的通用控制平面。它结合了数据平面和进阶的控制平面，允许用户使用本地自定义资源定义(CRDs)或RESTful API设置权限、获取指标和设置路由规则。Palladino解释说，早期第一代的服务网格产品大多缺乏成熟的控制平面，需要大量的二次开发或手工定制。

他解释说：“我们希望90%的用例都易于使用，并且能够快速升级。对于另外10%用例的用户，我们有一个允许用户深入使用的策略，”他补充说，尽管Kuma的设计是为了方便使用，“但Kuma是为企业设计的，而不是业余爱好者。”

Kuma的特性包括software-defined security，它支持所有四层通信流的mTLS身份验证；能够实现追踪(trace)和日志(log)记录，从而更好地分析指标；提供流量控制能力，如断路器和健康检查，以增强四层路由。

Palladino说，Kuma保护底层网络的能力提供了可靠性和更深层次的可观察性，并且无需修改任何代码。

Palladino说：“我们努力为Kuma构建一个非常平滑渐进的学习曲线。它的复杂度不会在早期压垮开发人员，并且也不会阻止开发人员走得更远。我们确实为高级用户提供了一个策略来配置底层代理数据平面。”

Kuma还利用了Kong同名的开源API网关。该网关管理组织与部署现代微服务的各种方法之间的信息流。

Kuma加入服务网格竞争行列

Kuma加入了服务网格竞争行列，这个群体与日俱增，声称可以更容易地支持微服务的部署。

Palladino说：“每个人都告诉我们，他们想要使用服务网格，但实际上没有一种服务网格易于使用，而且真正适用企业生产环境。许多企业专注于Kubernetes，但对他们来说，这成为了云原生探索之旅的终点。我们提供了一个产品，允许他们拥有一个可以更早实现并支持他们迁移的服务网格。”

一个已经引起广泛注意的服务网格平台是Istio。它定位于网络层，使用底层进行微服务开发和维护。这允许将管理运维与应用程序开发分离开来。

Palladino说，Istio帮助照亮了这片天空，但它仍然“非常复杂，有很多活跃的部件”。它在Kubernetes上运行得很好，但并不是所有人都在运行Kubernetes。”

他说，这种关注还会影响Linkerd和Containous等其他服务网格的选择，比如最近推出的Maesh平台。

“Maesh、Linkerd和其它控制平面网格都高度关注Kubernetes，”Palladino解释说。“只有当企业采用Kubernetes时，它们才会被采用。我们通过在这一过程的早期建立安全和可观察性，实现了向Kubernetes的过渡。”

还需要努力协调服务网格平台之间的互操作性。其中之一由微软牵头，它在今年早些时候率先推出了服务网格接口SMI规范。它的目标是为开发人员提供运行在Kubernetes上的不同服务网格技术的互操作性。

Palladino将这种努力淡化为边缘化服务网格功能。

“我们根本不相信SMI，”他说。“这是将接口标准化的另一种尝试，让它变得平庸而不优秀。它采用整个社区所有服务网格的公分母，从而降低了它们对最终用户的价值。它界限很宽，但并不深入。”

Palladino认为Kuma才真正实现了可以在所有平台进行互操作。

Kong以Mashape的名字成立于2009年。2015年，它将Kong平台发布到开源社区，并于去年对旗下所有业务产品正式启用了该平台的名称。该公司已通过5轮融资筹集了6,910万美元资金，最近一次是在3月份的C轮融资，总额4,300万美元。

编者后记

当Istio因其性能表现疲软之际，会涌现一个又一个的新玩家，给市场带来竞争与多样性，这也是用户喜闻乐见的。Kong涉足服务网格并不算太意外，我们可以了解到除了市面上的传统云厂商打造的和开源的各项服务网格产品，Consul Service Mesh的出现也让人眼前一亮。Consul Service Mesh与Kuma背后的厂商均有其成熟的开源产品做强力支撑：Consul的服务发现与注册产品，Kong的网关产品。他们各自在开源社区拥有一片天下，此时推出服务网格产品自然会有一大批“拥趸”。

Kuma的性能较之Istio以及其它服务网格产品的优劣尚未可知，但是其平台中立的思想还是值得借鉴。当前市场上，K8s并未完全普及，很多公司的产品都是部署在虚机甚至裸机上，如果此时又想尝试下服务网格技术，Kuma的出现不失为一种惊喜。

2018 年 9 月 30 日，腾讯迎来成立 20 年以来最具变革意义的组织架构调整——至今已经整整一年的时间。

在这次架构调整中，腾讯宣布了技术委员会即将成立的消息。100 天后，腾讯技术委员会正式成立；下设「开源协同」、「自研上云」两个项目组及「对外开源管理办公室」，计划发力内部代码的开源和协同，并推动业务在云上全面整合。

由此，开源协同成为腾讯在技术发展层面的一个关键词。

开源协同：为打破内部壁垒而来  

对于开源协同，腾讯在集团决策层面有着非常深入的思考；腾讯高级执行副总裁、技术工程事业群总裁卢山表示：

提出开源协同，就是希望以开源的手段来改善过去协同不好的问题。参考开源社区的组织方式，将同类项目的不同技术团队聚合在一起，开源共建。能合当然好，不能合也互通有无，开源坦诚相见，接受使用者的自然选择。

从腾讯技术自身发展的层面来说，开源协同也是一个自然而然的结果。

腾讯技术委员会 PMO 成员、开源协同项目负责人郑亚峰在接受雷锋网采访时透露， 2018 年，腾讯在技术层面遭到了一系列来自外界的质疑和批评，腾讯内部论坛也出现了一些匿名吐槽，这件事情真正地触动了腾讯技术人员。郑亚峰表示：

过往我们有很多引以为豪的技术，为什么到了去年，外界突然开始质疑腾讯的技术实力？我们一直在反思这个问题。之前公司内部确实有一些技术壁垒，部门与部门之间的隔阂太多了，同样的技术有多个团队在做。因此，我们做开源协同的初衷就是要打破壁垒，最主要的是形成开放的技术氛围和代码文化，开源协同是实现这个目标的手段。

显然，腾讯技术委员会的正式成立成了腾讯开源工作的一个转折点。

雷锋网了解到，在技术委员会成立之前，腾讯的开源文化是自下而上的，公司层面对此没有硬性规定，技术人员通常会自发推进关于前端的，或是工具类的一些开源项目；但这种方式很难推动和业务捆绑紧密、更底层的重量级项目开源——而腾讯技术委员会成立后，自上而下的开源协同机制建立，恰好能解决这一问题。

不过，在具体的运作方式上，所谓自上而下的开源协同，其实并没有专门的团队来负责，内部开源也不分项目，除了需保密的业务逻辑，所有的代码都要开放，算得上是“倾全公司之力”在做（全腾讯两万多名技术人员全员参与）。换句话说，技术人员仍在做自己的本职工作，只是工作的方式发生了变化——开源方面，之前代码对小组/部门开放，现在是对全公司开放；协同方面，之前是同一个技术是几个团队各做各的，现在是各团队一起协同开发。

这样一来，整合资源就变得更加容易，研发效率和代码质量进一步提升，同时运营成本也得到了优化。

不过，腾讯协同开源的路也并非走得一帆风顺。

郑亚峰告诉雷锋网，腾讯在开源协同方面遇到各种问题，其中，最大的困难是统一人心。在开源协同的过程中，难免会涉及到一些利益相关问题。在这种情况下，就需要上层来决定什么项目应该贡献出来，哪些团队应该参与；当然，上层并不会使用强硬的手段把大家捆绑在一起，而是通过协调和沟通来解决问题。

新代码文化：开源是手段，协同是结果

开源协同的推进不仅打破了腾讯各个部门之间坚硬的技术壁垒，极大地提升了研发效率；更重要的是，它还带来了更有意义的改变，比如说代码文化的升级。正如腾讯副总裁姚星在腾讯内部技术社区码客上回应一位普通开发者提出的问题时所言：

开源协同是目前腾讯研发体系升级很重要的一个方法，开源是手段，协同是结果。开源的目的是减少‘重复造轮子’，权限开放、代码相互可见。协同的目标是‘去中心化’， 能使用开源组件，能复用必复用；开源组件去 BG 部门属性，共同拥有腾讯属性；开发人员是开源组件的共同的参与者和创作者，不是甲方和乙方，从而保持快速的响应。

实际上，腾讯代码文化的诞生，可以回溯到 2013 年；当时，在公司 “开放” 战略升级的背景下，腾讯提出了代码的 “开放、复用和合力开发”。在 2018 年进行 930 变革之后，“新代码文化” 的概念应运而生，即：开源，协同，云上生长。

为了切身解决研发人员遇到的问题，推动新代码文化的发展和快速落地，腾讯内部技术社区的建设也开始走上正轨。

2019 年 1 月 2 日，在技术委员会的指导下，名为“码客”的技术社区上线，腾讯员工可以在此交流技术问题、学习编程知识。雷锋网了解到，在近 10 个月的时间内，每个月有超过 80% 的技术人员访问码客社区进行技术讨论，社区上提问数量近 3000 个，回答与评论达 15 万次，94% 的技术难题都得到了回复。

值得一提的是，2019 年 6 月，腾讯还开了一次 “吐槽大会”，辩论双方就 “开源协同是否有助于提高公司研发水平” 的问题展开了讨论；无论是从现场投票的结果来看，还是腾讯在 CI、大数据、编码器等方面的实际情况来看，吐槽大会的主题问题已经得到了肯定的回答。同时，这场吐槽大会也为技术委员会与公司技术人员创造了直接对话的机会，技术人员在现场提出的 70 多个问题，现在基本全部解决。

郑亚峰表示：

开源协同也是为了解决内部同事寻求技术帮助的诉求。我们做了一些技术工具，除了码客，还有技术图谱和工蜂 Git（雷锋网按：腾讯工蜂 Git 负责承载腾讯全公司的软件工程代码管理，功能涵盖代码仓库、代码评审、研发动态和开源协作）。现在，技术人员能够在固定的地方找到之前开源或者不开源的技术，然后直接拿来用。Talk is cheap，show me the code（什么话都不要说，把代码摆出来亮一亮）的氛围也越来越浓。

在腾讯内部，曾有人调侃腾讯就像技术的迷宫，但在开源协同的大背景下，腾讯技术人员有了不一样的感受。开源协同项目腾讯 CI 负责人、腾讯蓝鲸产品中心总监党受辉表示，最大的变化是团队更稳定了，也更有活力了；以前，很多工程师只是把写代码当成工作，倡导内部开源之后，这就从一份工作变成了带有感情的事业。

开源协同项目天穹、腾讯大数据负责人刘煜宏也表示：

开源协同之后，技术人员的参与感提升了，以前平台是个黑盒子，现在有了一个公开的渠道可以让所有开发者参与平台建设，大家很多好的 idea 和代码，都可以往里面贡献了。另外，以前可能有好几个团队都做同一个事情，重复造轮子，现在可以整合资源，资源更集中了，可以聚焦解决很多问题。

对外开源：前人栽树，后人乘凉

当然，腾讯在花大力气做内部开源协同的同时，对外开源的脚步也一刻没有停歇。

腾讯在对外开源始于 2016 年，主要是将内部开源出来的优质项目在 GitHub 上发布；到了 2019 年，伴随技术委员会的成立，腾讯开始耕耘更具影响力的项目，包括万亿级的大数据项目 TubeMQ，与 TensorFlow 互补的机器学习 Angel 平台等，以及最近开源的物联网操作系统 TententOS tiny。

那么，一个项目从内部开源走向对外开源，中间会经历什么样的考量？

对此，腾讯方面表示，一个项目要对外开源，首先都要在内部开源 “试水”，进入评选机制，结合客观数据和专家的评定，达到优秀项目的水平才会对外开源；除此之外，还要考虑业界的因素，如果业界同类的产品不多，对外开源才更有价值。不过，并不是所有对外开源的项目都需要很高的技术含量，因为很少有企业或用户能达到那种量级，因此，通用性也是一个重点考虑因素。

腾讯开源联盟主席、腾讯开源管理办公室委员堵俊平还提到了另一个考虑因素——看人。他说：

每个开源项目背后都需要团队的支撑，如果大家只是为了开源而开源，团队本身没有推动开源或者社区运营的能力和意志，我们并不鼓励。因为对外开源就意味着对用户负责。我们始终坚持“社区优于代码”，代码不好可以优化，但没有“好的人”，代码再好也可能石沉大海。

虽然腾讯在对外开源方面取得了可观的成果，但这数年背后的艰辛也不可忽视。腾讯副总裁王巨宏对此深有感触：

每次对外开源，人力物力的耗费是一方面，团队还要顶着巨大的压力。当时，TARS 团队表示想做开源，我们配合他们牵头推进，花了巨大的精力，甚至把相关专利捐赠给基金会，这是前所未有的（雷锋网按：TARS 是腾讯 2018 年 4 月开源的一款微服务框架）。我们还把散落在外面的开源项目回收，重新规划和宣传。除了技术人员，我们的安全团队、法务团队、知识产权管理团队等都付出了非常多的努力。

当然，腾讯的外部开源其实还反过来促进了内部开源协同的发展。

王巨宏表示，腾讯在对外开源方面走过的每一条弯路，遇过的每一个挫折都没有白费，而是以宝贵经验的形式回馈到了内部的开源协同上；如果没有腾讯多年来对外开源的积累，内部在开源协同的管理及制度建设方面可能还要摸爬滚打很长一段时间。

雷锋网小结

对于迎来 930 变革一周年的腾讯来说，无论是内部开源协同还是对外开源，其表现都可圈可点。在内部的开源协同方面，腾讯已经开展了 8000 个开源项目和 50 个协同项目，其中的代表性项目有腾讯 CI、TianQiong（天穹）、Kubernetes（k8s ）等；而在对外开源方面，截止 2019 年 9 月，腾讯已在 Github 上发布 84 个开源项目，累计获得的 Star 数超过 24 万 。

但显然，伴随着腾讯全新战略的向前推进，腾讯在开源这条路上有更长的路要走——正如腾讯开源协同项目负责人郑亚峰所言：

“开源” 本身操作起来很简单，但要把腾讯过往 20 年的代码都开放出来，需要花费巨大的时间和精力……我们给自己设定了一个目标，用 3-5 年的时间去建设开源文化和氛围；由于新技术会不断出现，所以协同是一个持续性问题，需要花更长的时间。

前言

一个公司的安全建设需要大量的物力、人力，由于网络安全在企业没有实际利益产出，常常在企业网络安全建设中，没有足够的投入（废话，投入没有经济效益回报，为什么要投入），但是企业网络安全建设不只是针对经济效益，它更像是一种保险（等出了事情，数据丢失，被网安抓典型处理），它更是一种对主业务的辅助（信息化辅助生产，甚至代替生产），但巧妇难为无米之炊，要对企业内网形成一套完整的纵深防御体系需要许多的商业化解决方案，无奈呼信息安全部门在一些企业中就是一个背锅的角色，为了能把锅抗好。。嗯，还是最好没锅吧！毕竟真的扛不动

闲话少说，纵深防护体系的第一道就是下一代防火墙，下面是下一代防火墙的简单配置介绍：

一、说明

1.1 pfSense是什么

pfSense是基于FreeBSD的、开源中最为可靠（World’s Most Trusted Open Source Firewall）的、可与商业级防火墙一战（It has successfully replaced every big name commercial firewall youcan imagine in numerous installations around the world）的防火墙。

简单点说pfSense就是一个操作系统形式的防火墙。更多介绍见： https://www.pfsense.org/getting-started/

二、pfSense安装

整个安装过程也不是很复杂，官方安装文档见： https://www.netgate.com/docs/pfsense/install/installing-pfsense.html

在虚拟机中安装使用（操作系统）freedbs 11 进行安装

2.1下载

下载地址： https://www.pfsense.org/download/

下载镜像iso即可

2.2安装

首选创建一个虚拟机，其他的都无所谓但是系统一定要FreeBSD。

到这步后所有的选项都是直接点击下一步，虚拟机创建完成后点击编辑虚拟机配置，添加网卡

因为防火墙至少需要两块网卡，所以需要创建至少2块网卡，一个网卡作为lan口，一个网卡作为wan口（也可以多个网卡），我们留一个网卡作为wan口（NAT模式），一个作为lan口（主机模式或者自定义），登录界面配置在lan口上，网卡只要启动两块就好了。

将ISO文件配置到虚拟光驱中，开启电源

回车接受版权声明

回车确认安装

选择键盘格式，默认是美国标准键盘，直接回车

选择文件系统，回车选择UFS，此步之后正式安装操作系统

直接回车选择重启完成安装

三、pfSense配置

3.1 设置pfsense接口

重启完成后会进入以下界面

不设置vlan（透明传输使用），设置wan口网卡，设置lan口网卡，最后输入Y进入系统

查看自己设置的网卡的网段le0 口因为使用dhcp直接通过即可，le1口作为lan口，必须使用le1口网卡的网段地址（主机模式下的DHCP分配期间地址）

设置接口地址，设置wan和lan的地址（只需要设置一个就可以，设置完成后需要将web界面到底是使用哪一个地址进行登录），在控制界面按 2 进入地址设置界面，设置一个lan口地址（设置为192.168.192.0/24 网段的地址），关闭dhcp（避免IP地址冲突），设置lan口为web管理口地址

设置完成后就可以登录了，通过上边14启动sshd后使用admin/pfsense也可以ssh登录操作系统

SSH账户名密码：admin/pfsense

3.2 web管理界面

访问设置为web登录的网卡地址，进行登录，默认用户名密码admin/pfsense

第一次登录后有有几步主机名、dns、时区等相关初始化向导，看着填不会就直接next

最后finish

点击finish大约30秒后进入该界面

设置完成后设置中文显示，依次点击SystemGeneral>Setup>Language，在下拉框中找到Simplified,china，选择之后点击该页面最下方的save

接下来就可以按照正常防火墙进行配置了

最后：在非常苛刻的条件下，可以使用三层路由的方式，使用各种开源的系统级防护系统，通过多个不同的主机网络将所有的设备串联起来，放置于网络的出口，以便进行内网安全防护，嗯，就是这样（说多了都是泪，都是被逼的。）

最后送上一些基础软件

vmware 15

链接： https://pan.baidu.com/s/1q0janMOCtIFbiApRfEgrfA

提取码：hqou

pfsense

链接： https://pan.baidu.com/s/10Va4z6f69FkCjpY29X0JNA

提取码：7o1w

*本文作者：寂静尘埃，转载请注明来自FreeBuf.COM

刚刚，在腾讯2019Techo开发者大会的现场，腾讯对一众开源项目进行了联合发布，并首次公开20年技术积累，指出未来云计算领域的三大技术趋势。

大手笔开源：容器平台TKE、数据库TBase等

截至目前，腾讯共开源了86个项目，覆盖云计算、大数据、AI、安全、小程序等领域，参与贡献的人数超过1000 名，累计在GitHub获得了超过 25万个 Star。同时，腾讯也是Apache基金会、Linux基金会、CNCF基金会和OpenStack基金会的顶级白金赞助商。

腾讯开源联盟主席堵俊平首先介绍了TubeMQ项目。TubeMQ是腾讯大数据从7年前就开始研发的一款分布式消息中间件，七年内支撑了腾讯的海量数据业务，目前每天支撑的数据量超过30万亿条。特点是支持数据的高性能存储与传输，吞吐率非常高，延迟低至5ms。本周，TubeMQ正式被Apache基金会接受为正式Incubator项目，开始孵化之旅。

第二个项目是腾讯Kona JDK。腾讯Kona JDK在主流OpenJDK8的基础上，进行了针对性的开发和优化， 引入了一些高版本JDK的特性，能够帮助用户在无感知的使用共享核心类信息来提高启动速度。在云场景下，JVM的启动速度最高能够提升到40%左右。

github 地址： https://github.com/Tencent/TBase

PingWest品玩12月19日讯，据 CNBC报道，亚马逊、苹果、Google和Zigbee Alliance正在联手开发一种开源智能家居标准，旨在改善其智能家居设备的兼容性，简化新设备的开发并确保开发、使用安全。这四家企业准备成立名为“家庭互联IP专项小组”（Project Connected Home over IP）的组织，未来宜家、三星SmartThings和Signify等公司也将加入。

该项目希望，用户无论购买的是哪家的智能家居设备，都能够配合已有的智能手机或语音助手，从而获得无障碍的体验。

根据IDC 9月份的数据，“全球智能家居设备市场预计将在2019年同比增长23.5％，达到近8.15亿台设备出货量。” 预计到2023年，这一数字将增长到13.9亿台。要实现这一目标，并且为了使消费者保持理智，消费者将需要某种标准，使所有事物彼此对话。

网址： https://sserr.net

代码： https://github.com/coyove/iis

之前的发布： https://v2ex.com/t/628871

时隔一个多月，当初的 todo 基本上都清掉了，代码也重构到了开源出去也不会太丢人的程度 XD。

总的来说这是一个类微博的系统，提供了大部分你所熟知的微博功能。时间线合并（ timeline merging ）采用读扩散，所以可以轻松的支持热点用户推文分发至海量 follower 的情况。回复 /@/收藏等则是写扩散。

后端采用纯 KV 形式存储，目前有两种实现（ dynamodb 和基于本地文件系统）。KV 不要求事务支持，所以理论上任何支持 set(k, v)和 get(k)的 IO 都可以用作存储驱动。（ dynamodb 会有 stale read，要解决这个问题需要本地缓存，如 redis ）

由于该架构设计特点，（以 dynamodb 为例）当一个账户 follow 的其他账户数目超过 10000 时合并延迟和性能会受比较大影响。但在另一方面，时间线合并的负担绝大部分在客户端，所以对于后端来说没有任何压力。

成熟的XA事务管理器非常多，Apache ShardingSphere（Incubating）并未选择重新造轮子，而是寄望于打造一个生态，将合适的轮子有机地整合在一起，提供成熟稳定的分布式事务处理能力。它的主要功能如下：

1.   复用成熟引擎，自动切换底层实现

Sharding-transaction-xa模块进一步定义了面向XA事务管理器开发者的SPI，开发者仅需实现SPI定义的接口，即可自动加入至Apache ShardingSphere（Incubating）生态，作为其XA事务管理器。

Apache ShardingSphere（Incubating）官方目前实现了基于Atomikos和Bitronix的SPI，并且邀请了Radhat JBoss的XA事务引擎Narayana [https://github.com/jbosstm/narayana] 开发团队实现了JBoss的SPI。用户可以自行的在Atomikos，Bitronix和Narayana间选择自己喜欢的XA事务管理器。

受限于Apache基金会项目License的原因，Apache ShardingSphere（Incubating）将采用Apache协议的Atomikos作为其默认实现，关于基于LGPL协议的Bitronix和基于LGPL协议的Narayana，用户可以自行引用相应jar包至项目的classpath即可。

如果这3个XA事务管理器仍未满足用户需求，开发者则可通过扩展SPI来实现定制化的XA事务管理器。

2.   数据源透明化自动接入

Apache ShardingSphere（Incubating）能够自动将XADataSource作为数据库驱动的数据源接入XA事务管理器。而针对于使用DataSource作为数据库驱动的应用，用户也无需改变其编码以及配置，Apache ShardingSphere（Incubating）通过自动适配的方式，在中间件内部将其转化为支持XA协议的XADataSource和XAConnection，并将其作为XA资源注册到底层的XA事务管理器中。

XA模块的架构图如下：

★Saga事务—跨越柔性事务限制，实现自动补偿★

在柔性事务中，每一次对数据库的更新操作都将数据真正的提交至数据库，以达到高并发系统中最佳资源释放的效果。当数据出现问题需要回滚时，通过柔性事务管理器保持数据的最终一致性以及隔离行为。Apache ShardingSphere（Incubating）采用Apache ServiceComb Saga Actuator [https://github.com/apache/servicecomb-saga-actuator] 作为Saga事务管理器，它的主要功能如下：

1.   自动反向补偿

Saga定义了一个事务中的每个子事务都有一个与之对应的反向补偿操作。由Saga事务管理器根据程序执行结果生成一张有向无环图，并在需要执行回滚操作时，根据该图依次按照相反的顺序调用反向补偿操作。Saga事务管理器只用于控制何时重试，合适补偿，并不负责补偿的内容，补偿的具体操作需要由开发者自行提供。

另一个柔性事务管理器TCC与Saga理念相似，均需要由使用方开发者提供补偿操作。除了补偿，TCC还提供了资源占用的能力，但也需要由使用方开发者提供资源占用操作。虽然功能上强于Saga，但TCC的使用成本较之Saga也更高。

由使用方开发者提供资源占用和补偿操作，这就使得柔性事务的解决方案始终难于大规模的在业务系统中落地。并且由于业务系统的介入，使得柔性事务框架的使用范畴始终定位于服务而非数据库，数据库能够直接使用的成熟的柔性事务管理器目前还不多见。

Apache ShardingSphere（Incubating）采用反向SQL技术，将对数据库进行更新操作的SQL自动生成数据快照以及反向SQL，并交由Apache ServiceComb Saga Actuator执行，使用方则无需再关注如何实现补偿方法，将柔性事务管理器的应用范畴成功的定位回了事务的本源——数据库层面。

对于能够处理复杂查询语句的Apache ShardingSphere（Incubating）SQL解析引擎来说，插入/更新/删除等语句解析难度则要小很多；ShardingSphere是通过拦截用户执行的SQL进行数据分片的，所有的SQL都能够被其直接管控。因此将反向SQL和补偿能力与Apache ServiceComb Saga Actuator相结合，达到了自动化柔性事务的能力，是数据分片和柔性事务结合的典范。

管理系统模版

前言

一套管理系统基础模版，提供了些基础功能（包含：系统用户，菜单，权限，调度任务，常量，数据字典等功能） 方便开发人员专注于业务功能开发。

项目前后端分离，前端采用 vue+element-ui，后端采用 spring-boot

项目地址：

https://github.com/cuteJ/shop...（后端）

https://github.com/cuteJ/shop...（前端）

项目简介

项目结构

前端

src -- 源码目录
├── api -- API
├── assets -- 图片资源文件
├── components -- 通用组件
├── directive -- vue指令
├── filters -- 过滤器
├── lang -- 国际化配置
├── icons -- svg文件
├── router -- 路由配置
├── store -- vuex状态管理
├── styles -- 全局css样式
├── utils -- 工具类
└── views -- 页面组件
    ├── app -- 应用管理（小程序）
    ├── dashboard -- 首页
    ├── errorPage -- 错误页面
    ├── layout -- 布局页面
    ├── login -- 登录页
    ├── profile -- 个人配置
    ├── svg-icons -- 图标
    ├── system -- 系统管理
        ├── components -- 页面级别组件
        ├── sysApiListManager -- 接口列表
        ├── sysAuthorityManager -- 接口权限
        ├── sysDicManager -- 常量管理
        ├── sysJobManager -- 定时任务
        ├── sysJobRunLogManager -- 定时任务日志
        ├── sysMenuManager -- 菜单管理
        ├── sysMetadataManager -- 数据字典
        ├── sysOptLogManager -- 操作日志
        ├── sysRegionManager -- 地区管理
        ├── sysRoleManager -- 角色管理
        ├── sysUserManager -- 系统用户管理
    ├── user -- C端用户管理
        ├── userLoginManager -- C端用户列表

后端

shop-server├── install -- 脚本文件
    ├── shop-server-api -- 公共模块（包含 model mapper 工具配置类等）
    ├── shop-server-app （包含 H5登录，各类小程序登录） 
    ├── shop-server-mgt 

运行架构

​ 体量小的项目实行单一运行架构，nginx 完全承担了静态文件服务器，和后端应用代理。

如需CDN，或者后端扩展，具体部署架构根据自身项目情况而定。

基本功能

权限

权限设计分为前端和后端，前端根据返回的后台菜单权限数据控制菜单页面显示与隐藏。

后端采用 Shiro框架实现权限的控制。

用户权限数据库表模型

项目前端界面：

定时任务

定时任务采用 quartz进行简单 封装实现。

数据库模型

项目前端界面

其它

数据字典

总结

项目正在起步阶段，目前完成1.0.0，待测试。后续开发计划.....

• 项目1.x 分支基础模版（后续会继续更新）
• 计划新增2.x分支，添加业务功能（如：订单，商品等）

“

本文已经收录进我的 75K Star 的 Java 开源项目 JavaGuide： github.com/Snailclimb/…相关阅读： V2.0 版本的 《JavaGuide面试突击版》来啦！带着它的在线阅读版本来啦！

大家好，我是 Guide 哥，一个三观比主角还正的技术人。推荐阅读：

今天推荐几个 Java 项目快速开发脚手架，解放双手 ✋ 从现在开始。

以下推荐项目都是码云上的优质项目，并且都是项目快速开发脚手架，代码质量什么的无法保证能有多好，毕竟很多也是个人开发，或多或少也有个人色彩影响。

不过既然开源出来，这么多人参与，一般情况下项目整体质量可以说是非常不错的了。另外，下面推荐的项目几乎都是码云上面选出来的最有价值的开源项目。后面，可能会单独再推荐一期 Github 上的 Java 项目快速开发脚手架。

想要获取更多开源项目资源？欢迎关注我的 awesome-java（Github 上非常棒的 Java 开源项目集合），地址： github.com/Snailclimb/…。

概览：

1. Guns
2. pig
3. RuoYi
4. Jeecg-boot
5. iBase4J

Guns

推荐指数：⭐⭐⭐⭐⭐

简介

我在上大学的时候就了解和接触过了这个项目，当时我还是一个 Spring 入门不太久的小菜鸟。一晃，不经意间已经过去快 3 年了。

1. 采用主流框架： 基于 Spring Boot2.0+版本开发，并且支持 Spring Cloud Alibaba 微服务。
2. 功能齐全：包含系统管理，代码生成，多数据库适配，SSO 单点登录，工作流，短信，邮件发送，OAuth2 登录，任务调度，持续集成，docker 部署等功能；
3. 提供了企业版：企业版功能更多，并且提供了完善的开发文档，开发 demo，快速入门。

相关地址：

1. 项目地址 ： gitee.com/stylefeng/g…
2. 项目官网 ： www.stylefeng.cn/

另外，这个项目还提供了视频教你如何使用，地址：https://www.bilibili.com/video/av56718207 。

推荐理由

1. 项目技术主流，唯一缺点是企业版和微服务版需要单独购买。
2. 社区活跃。
3. 项目功能完善，满足企业绝大部分场景开发需求，并且额外提供了持续集成，docker 部署等功能。
4. ......

适合场景

适合企业后台管理网站的快速开发场景，不论是对于单体和微服务都有支持。

项目展示

pig

推荐指数：⭐⭐⭐⭐⭐

简介

这个项目之前就推荐过几次，你可以在这个视频： www.bilibili.com/video/BV1b7…中找到。

根据项目官网，简单说下这个项目：

1. 基于 Spring Cloud Hoxton 、Spring Boot 2.2、 OAuth2 的 RBAC 权限管理系统
2. 基于数据驱动视图的理念封装 element-ui，即使没有 vue 的使用经验也能快速上手
3. 提供对常见容器化支持 Docker、Kubernetes、Rancher2 支持
4. 提供 lambda 、stream api 、webflux 的生产实践

相关地址：

1. 项目地址： gitee.com/log4j/pig
2. 官网地址： pig4cloud.com/

推荐理由

1. 社区活跃；
2. 提供了 Spring Cloud Hoxton & Alibaba 的微服务版本；
3. 权限管理做得不错！
4. 功能完全开源！
5. 支持第三方系统比如 guns、renren 接入
6. ......

适合场景

项目展示

RuoYi

推荐指数：⭐⭐⭐⭐

简介

项目名字是作者还未出生的女儿，看到之后很感动！

RuoYi 一款基于基于 SpringBoot 的权限管理系统 易读易懂、界面简洁美观，直接运行即可用 。

作者是这样介绍这个项目的：

“

一直想做一款后台管理系统，看了很多优秀的开源项目但是发现没有合适的。于是利用空闲休息时间开始自己写了一套后台系统。如此有了若依。她可以用于所有的 Web 应用程序，如网站管理后台，网站会员中心，CMS，CRM，OA。所有前端后台代码封装过后十分精简易上手，出错概率低。同时支持移动客户端访问。系统会陆续更新一些实用功能。

性别男，若依是给还没有出生女儿取的名字（寓意：你若不离不弃，我必生死相依）

相关网站：

1. 项目地址 ： gitee.com/y_project/R…
2. 文档地址 ： doc.ruoyi.vip/
3. 官网地址： ruoyi.vip/

推荐理由

1. 提供了多种版本：单体、前后端分离、微服务（即将开源）
2. 提供的功能齐全，覆盖大部分场景需求
3. 提供的文档丰富便于上手和学习
4. 生态系统丰富提供了多种版本
5. 采用主流框架比如 SpringBoot、Shiro、Thymeleaf、Vue、Bootstrap
6. ......

适合场景

她可以用于所有的 Web 应用程序，如网站管理后台，网站会员中心，CMS，CRM，OA。

项目展示

Jeecg-boot

推荐指数：⭐⭐⭐

简介

这个项目同样在我上大学那会就很火了！简单从下面说几个方面介绍 Jeecg-boot 吧！

1. 低代码：JeecgBoot 是一款基于代码生成器的 J2EE 低代码快速开发平台。强大的代码生成器让前后端代码一键生成，无需写任何代码!
2. 采用主流框架：整体采用现在流行的前后端分离架构：后端框架为主流的 SpringBoot 2.x，前端为主流的 Ant Design&Vue。另外，还用到了 Mybatis-plus 数据库层面的框架，以及 Shiro 和 JWT 做身份认证和权限管理。
3. 整体灵活实用： 简单功能由 Online Coding 配置实现，帮助 Java 项目解决 70%重复工作，复杂功能由代码生成器生成进行手工 Merge。让开发更关注业务逻辑，既能快速提高开发效率，帮助公司节省成本，同时又不失灵活性。

相关地址：

1. 项目地址： gitee.com/jeecg/jeecg…
2. 在线演示 ： boot.jeecg.com
3. 技术官网： www.jeecg.com

整个项目的技术架构如下图所示，README 文档已经贴好了，我就直接复制过来了。

推荐理由

1. 采用主流框架，前后端分离，对开发比较友好；
2. 用户管理和权限权利模块做的非常好，满足绝大部分人员管理场景的需求。权限控制采用 RBAC（Role-Based Access Control，基于角色的访问控制） ，支持菜单动态路由。
3. 提供了 Excel 导入导出、报表工具等必备功能。
4. 自带消息中心，支持短信、邮件、微信推送等等。
5. 页面校验自动生成(必须输入、数字校验、金额校验、时间空间等);
6. 平台 UI 强大，实现了移动自适应，无需再为移动端适配；
7. ......

适合场景

Jeecg-Boot 快速开发平台，可以应用在任何 J2EE 项目的开发中，尤其适合企业信息管理系统（MIS）、内部办公系统（OA）、企业资源计划系统（ERP）、客户关系管理系统（CRM）等，其半智能手工 Merge 的开发方式，可以显著提高开发效率 70%以上，极大降低开发成本。

项目展示

iBase4J

推荐指数：⭐⭐

简介

简单来说：

1. 分布式架构：iBase4J 是 Java 语言的分布式系统架构。
2. Maven 模块化管理： 使用 Maven 对项目进行模块化管理，提高项目的易开发性、扩展性。
3. 子系统扩展性强：子系统之间使用 Dubbo 或 MQ 进行通信。
4. ......

相关地址：

1. 项目地址： gitee.com/iBase4J/iBa…

技术选型如下：

• 核心框架：Sring boot + Spring Framework + Dubbo + ibase4j-common
• 安全框架：Apache Shiro
• 任务调度：Spring + Quartz
• 持久层框架：MyBatis + MyBatis-Plus
• 数据库连接池：Alibaba Druid
• 缓存框架：Redis
• 会话管理：Spring-Session
• 日志管理：SLF4J、Log4j2
• 前端框架：Angular JS + Bootstrap + Jquery

推荐理由

1. 分布式架构，但是用的是 Dubbo，如果有 Spring Cloud 版本就好了。
2. 支持 QQ、微信、新浪微博第三方登录。
3. 自带 excel 导入导出，汉字转拼音，身份证号码验证，数字转大写人民币，FTP/SFTP/fastDFS 上传下载，发送邮件，redis 缓存，加密等等工具类
4. ......

适合场景

分布式企业管理系统的场景。

项目展示

本文使用 mdnice排版

Kubernetes

Prometheus

Envoy

CoreDNS

Containerd

Fluentd

Jaeger

Vitess

TUF（The Update Framework）

Helm

编者按
谈到大数据就会联想到Hadoop、Spark整个生态的技术栈。大家都知道开源大数据组件种类众多，其中开源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等。当前企业对大数据的研究与应用日趋理性，那么，如何根据业务特点，选择一个适合自身场景的查询引擎呢？
百分点在某国家级项目中承担了日增超5000亿级的数据处理与分析任务，集群的总数据量已接近百万亿。本报告结合百分点在项目中的业务场景，对HAWQ、Presto、ClickHouse做了综合评测，供大家参考。

一、测试整体方案

百分点面对的业务场景，主体是要解决超大规模数据集的Ad-Hoc查询问题，并且大多是单表查询场景。架构团队在此过程中选取了HAWQ、Presto、ClickHouse进行评测。评测中选取的数据集与SQL来自项目实际业务，我们需要评测维度主要如下：

A．数据在不同压缩格式下的压缩能力。

B．不同格式下的数据查询能力。

C．特定格式下的HAWQ、Presto、ClickHouse查询能力横向对比。

二、测试组件介绍

1.HAWQ

HAWQ是Hadoop原生SQL查询引擎，结合了MPP数据库的关键技术优势和Hadoop的可扩展性、便捷性，以及ANSI SQL 标准的支持；具有 MPP（大规模并行处理系统）的性能，比Hadoop生态圈里的其它SQL 引擎快数倍；具有非常成熟的并行优化器等。

2.Presto

Presto是一个分布式的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto是一个OLAP的工具，擅长对海量数据进行复杂的分析。但是，对于OLTP场景，并不是Presto所擅长，所以不要把Presto当做数据库来使用。

Presto需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。

3.ClickHouse

ClickHouse是“战斗民族”俄罗斯搜索巨头Yandex公司开源的一个极具"战斗力"的实时数据分析数据库，是面向 OLAP 的分布式列式DBMS，圈内人戏称为“喀秋莎数据库”。ClickHouse有一个简称"CK"，与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点包括：分布式、列式存储、异步复制、线性扩展、支持数据压缩和最终数据一致性，其数据量级在PB级别。

三 、测试环境

1.服务器硬件配置

大数据服务器：大数据网络增强型 d1ne

2.OLAP引擎环境

• HAWQ环境

• Presto环境

• ClickHouse环境

3.测试数据

数据存放路径：/data1~12/iplog，一个盘20G，6台服务器每台都是240G，一共1440GB；每台服务器12个盘装载4个分区（小时）数据，每个盘装载4个分区的1/12的数据，4个文件，每个文件大小5G，2500w条记录，一条记录200Byte。

4.测试SQL

测试挑选4个实际典型SQL，大致如下：

四、测试过程

1.HAWQ存储格式与性能评测

经过对比测试后，考虑数据的压缩比、数据的插入速度，以及查询时间这三个维度综合评估，我们的场景推荐HAWQ采用列式存储+Gzip5的压缩方式；如果大家对压缩没有非常高的要求，可以按照测试的详细数据采用其它的组合方式。

HAWQ压缩测试注意事项：只有当orientation=parquet的时候才能使用gzip进行压缩，orientation=row的时候才能使用zlib进行压缩，snappy不支持设置压缩级别。

详细的评测数据及图片展现如下文所示。

• 行式存储与压缩：

HAWQ的插入方式是将数据写入CSV文件后，Load到HAWQ表中。本次评测的是数据Load的过程和最终压缩比。可以发现，zlib压缩级别到5以后，压缩比的降低就不那么明显了。

测试明细：

结果图形展示：

• 行式存储查询性能：

测试明细：

结果图形展示：

• 列式存储与压缩：

测试明细：

结果图形展示：

• 列式存储查询性能：

测试明细：

结果图形展示：

2.Presto存储格式与性能评测

经过对比测试后，考虑数据的压缩比、数据的插入速度，以及查询时间这三个维度综合评估，我们的场景推荐Presto采用LZ4+ORC方式。这个结果也与各公司采用的格式一致。

• 存储与压缩：

测试方式，通过CSV文件Load到Hive表，原始数据总量为1440GB。

• 查询性能：

3.查询对比测试：HAWQ vs Presto vs ClickHouse

通过对比测试结果可以发现，在相同的数据量查询SQL情况下，ClickHouse对比HAWQ、Presto有数量级的性能优势。由于我们的业务更多是单表的Ad-Hoc查询和分析，因此本次评测最终采用ClickHouse作为我们的OLAP引擎。

同时，测试过程中我们也发现一些有意思的现象，如：

(1) HAWQ对查询都是全表扫描，如类似Select * from where c1=xxx limit 10查询，而Presto则对扫描的结果直接返回。

(2) HAWQ查询会使用到系统缓存，而Presto对这方面并没有特别的优化。表现出的现象就是，在一定的并发度下，HAWQ反而会体现出缓存的优势，而Presto性能则呈现线性下降趋势。

详细见测试过程的详细记录及图形化的直观展现。

• 并发1查询性能：

• 并发10查询性能：

• 并发20查询性能：

4.其它扩展测试

• Presto单机多Worker：

我们通过添加单机的Worker数量验证是否提高查询效率，提高单机的查询利用率。

单机增加Presto Worker，部署多Worker。测试结果：表现为CPU瓶颈，没有效果。如下图，可以发现每个Worker的吞吐也少了一半。

• Presto扩容：

我们通过添加扩容机器并部署Worker，验证查询性能影响。

加入新的机器，部署Worker。测试结果：表现为性能基本线性增长，受限于数据节点的磁盘IO和网络。

• ClickHouse 横向扩展查询测试：

测试横向扩展对查询性能的影响，每个节点的数据量是相同的，使用相同的SQL分别测试单节点、五节点、十节点的查询性能。

根据测试结果可以看出，横向扩展后，节点数和数据量等比增加，查询时间几乎保持不变。所以对于ClickHouse我们可以基于单节点的数据量和性能，推断一定场景下整个集群的情况。

测试明细：

结果图形展示：

• ClickHouse PageCache缓存查询测试:

测试PageCache对查询性能的影响，首先清除所有缓存分别查询四个SQL，然后再重复执行一次，可以发现，PageCache对第二次查询的性能提高是影响巨大的。

ClickHouse充分利用了系统缓存（PageCache），对查询有数量级的性能提升作用。

测试明细：

结果图形展示：

五、各组件综合分析

通过上述测试结果和分析图表，结合我们查询各组件的开源介绍进行综合分析，如下：

HAWQ采用基于成本的SQL查询优化器，生成执行计划；同时在标准化SQL兼容性这方面表现突出（基于TPC-DS进行SQL兼容性测试）。数据存储直接使用HDFS，与其它SQL on Hadoop引擎不一样，HAWQ采用自己的数据模型及存储方式。在本次对单表的查询测试中，性能并不理想，并且我们发现对于表查询类似limit 1语句。HAWQ也会全表扫描，这个过程让我们感觉有点诧异。

Presto的综合能力对比其他SQLon Hadoop引擎还是比较突出的。我们在测试过程中发现，单节点的扫描速度达5000WRow/S。Presto是完全基于内存的并行计算，对内存有一定的要求。只装载数据到内存一次，其他都是通过内存、网络IO来处理，所以在慢速网络下是不适合的，所以它对网络要求也是很高。Presto只是查询引擎，不负责数据的底层持久化、装载策略。Presto支持丰富的多数据源，可跨多个数据源查询。另外，在我们测试的版本上没有本地数据读取优化策略，开源社区里在新版本上是支持的。

ClickHouse作为战斗民族的开源神器，是目前所有开源MPP计算框架中速度最快的。对比测试的结果表明，ClickHouse在单表的查询中性能十分优异。对多表的关联分析场景，查询其他报告并不十分理想，本次测试并不涉及，不做评论。ClickHouse性能很大程度上依赖于系统缓存。对完全非缓存，进行磁盘扫描的场景，性能也不是十分突出，二者也有数量级的性能差距。这也是我们在使用过程中的优化点。

最后，以上采用MPP架构的OLAP引擎，随着并发的提高，查询性能都出现了线性下降，Presto在这个问题上的尤为明显。CK由于单次查询速度快，所以一定程度上掩盖了这个问题。因此，大家在未来的业务中进行OLAP评估时，也需要将并发作为一个重要的考虑因素。

本文转载自公众号百分点（ID：baifendian_com）。

原文链接：

https://mp.weixin.qq.com/s/XpuUr00kMagU_jrXiDu-6g