与子偕老
最近忙着系统重构，因为经常处于移动办公的状态，访问公司的服务器不是很方便，所以一些基础服务都是搭建在本机上。但是使用的时候碰到了一些问题，最大的问题是网络地址切换导致的：IP地址总是不固定。有些服务（例如FastDFS）需要有明确的IP地址来绑定服务。不固定的IP地址会给这些服务带来麻烦，需要修改配置重启服务。 这种情况下，最好的解决办法是能够给Mac分配一个固定的IP，不管怎么切换网络一直存在。幸好这个是可以解决的，而且并不复杂。方法如下：
1ifconfig lo0 alias 192.168.255.199
其原理是给网络设备loopback增加一个alias。loopback设备一直存在，而且与en0设备独立，可以一直存在。
因为云认证服务的商户认证体系是基于双向SSL的，如果服务器端没有启用SSL证书，则整个认证体系必须重构。目前的现状是申请SSL证书费用比较高（一年2-3w），而且周期比较长，赶不上目前的测试进度。所以只能使用免费证书来支撑一下了。
免费证书服务提供商据我所知有几个：Let's Encrypt, StartSSL, StarCom。但是StartSSL, StarCom前一阵子被Chrome、Firefox等设置为不可信（签名流程不规范，不符合安全监管要求之类的原因），因此目前可选的只有let's encrypt。
Let's Encrypt是国外一个公共的免费 SSL 项目，由 Linux 基金会托管，它的来头不小，由Mozilla、思科、Akamai、IdenTrust和EFF等组织发起，目的就是向网站自动签发和管理免费证书，以便加速互联网由 HTTP 过渡到 HTTPS。
Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。 Apache Kafka与传统消息系统相比，有以下不同：
之前一直使用Ubuntu 14.04来跑Docker。今天在16.04 LTS上跑Docker的时候发现设置DOCKER_OPTS的时候有些区别，特此记录一下。
Mac上找不到特别好的SOAP Webservice测试工具。以前用过SOAP UI，感觉很好。但是SOAP UI在Mac上安装有些问题。特此记录一下安装过程。
SoapUI目前最新的版本是5.3.0，目前已经开源。SmartBear在SOAP UI之后发布了新版本更名为SOAPUI NG。SOAPUI NG体积大了很多，而且功能更加繁琐，个人感觉还不如以前的版本好用。SoapUI以前收费，到了5.2.1以后版本就开源并且免费了。
SoapUI在Mac会出现无响应的现象：界面能够打开，但是画面卡住，鼠标显示成旋转彩球，无法操作。要正常使用需要修改一下才行。
项目中用到了FastDFS来做文件存储。最近重构的时候，因为经常处于移动办公的状态，所以访问公司的服务器不是很方便，所以感觉有必要在本机上搭建一套FastDFS的测试环境。
FastDFS是什么？
FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。 FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。 FastDFS里面有两种角色：Tracker、Storage。Tracker主要做调度工作，在访问上起负载均衡的作用。Storage存储节点存储文件，完成文件管理的所有功能：存储、同步和提供存取接口，FastDFS同时对文件的meta data进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key value pair）方式表示，如：width=1024，其中的key为width，value为1024。文件meta data是文件属性列表，可以包含多个键值对。
注： 这是在之前博客上发过的文章，在实际使用中经常会有人碰到，特意转贴过来。
目前公司对外开放了一个云服务平台，提供一些功能供商户接入使用。整个项目的架构是基于Spring + MyBatis的。另外，商户端的服务接口是基于SOAP WebService的，这部分使用CXF实现。 安全方面采用了Spring Security，可以对商户提供证书认证或密码认证。但是出于安全考虑，目前只开放了证书认证。为了使用证书认证商户，我们创建了一个自签名的CA，用来生成商户使用的客户端证书。在验证上，使用Nginx验证客户端证书是否是指定CA产生的。另外，为了防止被作废的证书（例如给商户颁发了新证书后，原证书应该作废，但是原证书也是由指定CA产生的）再次使用，在代码层面对证书进行了进一步的验证（这一点是通过Nginx将客户端证书作为Header传递到Java后台实现的，有时间以后再讲）。
1<filter>
2 <filter-name>springSecurityFilterChain</filter-name>
3 <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
4</filter>
5
6<filter-mapping>
7 <filter-name>springSecurityFilterChain</filter-name>
8 <url-pattern>/documentation/*</url-pattern>
9</filter-mapping>
用过Spring Security的人都会熟悉以上代码，一般教程上都会说明，使用Spring Security就需要在web.xml中指定以上代码。从这个配置中，可能会给我们造成一个错觉，以为DelegatingFilterProxy类就是springSecurity的入口，但其实这个类位于spring-web这个jar下面，说明这个类本身是和springSecurity无关。
虽然现在的SVN已经用的越来越少，很多人都切换到了Git上。但是以前的一些历史项目还是需要SVN支持的。 之前的SVN服务器是直接搭建在一台Ubuntu服务器上的。当时一起搭建了WebSVN。也曾经研究过怎么搭建WebSVN，但是现在也不能够工作了，时间长久了也忘了怎么搭建了。所以想研究一下怎么使用Docker来完成一样的工作。
最近运营同事在管理平台（生产环境）上碰到一个问题：登录之后会莫名其妙地变成未登录状态，被踢回登录页面。
管理平台使用的Spring MVC框架实现的后台接口，React实现的前台页面。之前引入React的时候已经做过前后端分离。但是当时考虑到技术栈的原因，没有对登录体系进行彻底改造，没有引入AccessToken来维护登录状态，依然保留了Java的Session机制。考虑到管理平台属于内部使用，访问量不大，因此直接在Nginx层使用iphash进行了Session粘滞，确保同一个用户的请求总是被同一个的后台Tomcat处理，这样就可以使用传统的session机制保持用户登录状态。