之前博客使用的是Nginx，证书是从let’s encrypt申请的。Nginx配置是比较多，但是从各种参考参考，还是能够配置的。唯一的问题是let’s encrypt证书需要定时更新，更新以后需要Nginx重新加载一下，操作上始终有些繁琐。

Caddy是一个综合解决方案，结合了防火墙、代理、证书等功能，最重要的是使用方便，配置简单。

从Nginx迁移只需要几分钟，我之前使用的docker-compose管理，所以配置如下

Caddy相关配置

caddy:
  image: abiosoft/caddy:1.0.3
  restart: always
  container_name: caddy
  external_links:
  - blog
  environment:
    - CADDYPATH=/etc/caddycerts
  ports:
  - 80:80
  - 443:443
  volumes:
  - /alidata/data/caddy/Caddyfile:/etc/Caddyfile
  - /alidata/data/caddy/certs:/etc/caddycerts

而最关键Caddy配置文件只有几行，主要就是代理一下，顺便强制跳转http到https

huangyunkun.com {
    redir https://www.huangyunkun.com{uri}
}

www.huangyunkun.com {
  redir {
    if 

文档对于软件来说是非常重要的一部分，特别是对于开源软件来说，在接触源代码之前，一般会先接触文档。

文档可以给新的使用者一个清晰的快速上手说明，也可以给已有使用者提供更多细节上的信息，帮助使用者更好的使用各种特性。

我认为一个合格的文档应该满足以下几个要求：

• 易于编写，由一种标准格式驱动，比如asciidoc或者markdown也可以
• 支持文档版本化
• 支持文档搜索
• 对于多语言翻译友好
• 支持多种格式用于离线浏览（比如pdf或者epub格式）

常用的做法有以下几种：

• 使用专用的网站/文档构建工具
• 选定一种文本格式，并使用相应工具链处理
• 文档直接附加在分发物中

使用专用的网站/文档构建工具

这是一种相对省心的方案，一般可以直接构建完整的网站，并附带对于文档的支持。

比如react-native使用的docusaurus，这是一个全套解决方法。对于文档本身使用markdown书写，对于多语言翻译使用的是crowdin工具，搜索支持来源于algolia。对于不同语言还有版本的支持都是基于目录的。而多版本切换入口在页面顶部的logo旁。

以react-native为例，版本切换在https://facebook.github.io/react-native/versions中，而不同版本路径如下：

https://facebook.github.io/react-native/docs/getting-started

https://facebook.github.io/react-native/docs/0.60/getting-started

类似的工具还有docsite、vuepress、docsify等，但是对比与docusaurus多多少少有一些功能缺失。

选定一种文本格式，并使用相应工具链处理

上面一种其实是网站+文档解决方案，如果只是需要文档，那么方案可以更纯粹一些。

可以参考spring-boot的方案，在spring-boot的项目中有一个spring-boot-docs文档，其中有adoc为后缀的文件。这些文件都是asciidoc格式的，通过asciidoc的maven插件生成对应的html、pdf、epub格式的文档，并上传到对应目录，而文档版本引导页面是自己独立编写。

这种操作的优势在于文档输出格式多，且网站样式自由度高，理论上只需要加上不同版本的链接即可。

文档直接附加在分发物中

对于功能比较直接的，可以直接将文档附加在分发物中，比如放在readme中，或者作为软件的一部分，比如命令行工具的help指令。这种一般针对于功能直接的小型软件。

Dubbo文档的管理

Dubbo目前的文档基于docsite建设，语法使用markdown语法，支持多语言（目录模式）。唯一的缺少的主要是两个

• 文档版本化
• pdf、epub等格式导出

版本化

文档版本化可以考虑简单思路就是仿造docsite用docusaurus一样的方式支持版本化。

目前Dubbo文档源文件目录如下：

而支持版本化的目录结构如下：

算法工程师和业务开发工程师掌握的技术集和工具是不同的，特别是当两者运用的语言不同的时候更严重。算法辛苦作出的模型业务开发用不了会极大影响很多事情的落地。

常见的合作模式如下算法负责模型训练和导出模型，业务开发导入模型并且做预测。一般算法使用python，R等，而业务开发使用java。可选的部署方法有以下几种：

实时小规模

可以简单点直接用Rserver或者python-httpserver，这种需要额外的服务，也存在调用问题，即引入了网络超时，重试等问题。性能上的话小数量可以保证95%在100ms返回，但是数据量大了就需要仔细控制。

实时大规模

这种情况考虑到基础设施的情况，特别是RPC框架等情况，同时要考虑水平扩展，最好使用PMML。这种额外依赖外部环境的方式可以提供较高的工程稳定性，但是PMML必然导致一些算法精度的损耗。

离线计算

对于T+1的计算和产出，部署上无疑最简单，直接使用脚本搭配一个监控和调度平台就可以获得较好的收益。

对于PMML，java中的选择是https://github.com/jpmml，对于各种语言和模型都有较好的支持。当然由于较高的通用性，PMML会丧失特殊模型的特殊优化，例如上线XGBoost模型，也可以使用XGBoost4J，该包会链接一个本地环境编译的 .so 文件，C++实现的核心代码效率很高。不过PMML格式通用性，在效率要求不高的场景可以发挥很大作用。…

升级maven插件

升级的第一个重点就是maven插件需要升级到最新版本，因为大部分项目还是在Java 8状态，而Java 9新增了Jigsaw，还有部分API的废弃，所以大部分maven插件都有相应的支持调整。所以插件版本是第一个需要升级的。

如果使用的插件比较多，可以使用versions-maven-plugin来检查可用的升级版本。

<plugin<groupIdorg.codehaus.mojo</groupId<artifactIdversions-maven-plugin</artifactId<version2.7</version<configuration<generateBackupPomsfalse</generateBackupPoms</configuration</plugin

执行mvn versions:display-plugin-updates

升级完成之后需要修改编译使用的版本，之前的maven-compiler-plugin需要指定source和target参数，现在只需要release参数就行了

<plugin<groupIdorg.apache.maven.plugins</groupId<artifactIdmaven-compiler-plugin</artifactId<version3.8.0</version<configuration<release11</release</configuration</plugin

另外由于JDK的升级，当有setAccessible(true)调用的时候会有warning消息

WARNING: Please consider reporting this to the

平时经常在自己的电脑上运行Docker，有时候是快速试用新东西，有时候是搭一个环境用一下，都不是长期使用的。久而久之Docker占用的空间越来越大。

网上有很多清理的脚本，可以清理的无非是以下几样：

• 关闭的没有运行的容器
• 没有tag的镜像
• 没有tag的数据卷

相关的命令网上也有，可以存储下来做成一个简单的命令。

还有一个方法就是用docker-gc镜像，命令如下：

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc
…