随着云计算的市场化，大部分企业选择在公有云上部署自己的应用。公有云自带成熟的运维解决方案，帮助企业更好专注于业务发展，节约系统运维成本。本篇文章重在总结如何在cloud外部跑我们的automation case。
相信大家在日常开发过程中，在编写我们的application service的时候都会写一些UT，帮助我们检测我们的代码逻辑是否正确，是否符合业务要求。后来为了减少人力成本，我们又开始研究自动化测试用例。让系统部署完成之后，直接就跑我们写好的，定义在关键路径上的case（包括UI，API等）。在本地环境上面或者在CI上面，run这些命令很简单，maven就足够了。但是一旦我们想在cloud上部署呢？会遇到哪些问题呢？
Q：为啥要在云上跑，我在CI环境上跑完case，通过之后，把应用直接扔到云上不就好了，为什么还要在云环境里再验证一次？
A：环境的差异性，为了尽量跟客户环境一致，需要在云上能够跑关键case。同时也是为了日后版本升级。
Q：那我可不可以把case直接作为一个服务，跟普通application service一样直接部署到云上？
A：这样做其实也可以，做成微服务的一环。但是有个不好的地方在于case版本和应用绑定过于紧密，而且跑在云上，cost不可忽视。
综上，优先考虑cost，（总不至于和钱过不去把，不能还没有盈利，沉默成本已经是巨头了）。想在cloud之外跑我们的automation case成为首选。case跑在任何一个vm上面，然后通过rest请求cloud上的应用。这样的方式首先想到的问题就是network。On premise的环境网络之间都是打通的，防火墙都是关闭的。但是云上环境肯定不一样的，安全要求很高。需要携带server端的cert，并且云上需要相应的开启端口，让服务暴露出来。归根结底还是网络传输的问题。在这里重温下什么是三次握手，四次挥手。
三次握手，四次挥手
三次握手
客户端要想和服务端建立连接，需要发送自己的请求建立链接。这个过程需要经历三次握手。这里面我们需要知道tcp标志位：有6种标示:SYN(synchronous建立联机)、 ACK(acknowledgement 确认) 、PSH(push传送）、ST(reset重置)、 URG(urgent紧急) 、Sequence number(顺序号码) Acknowledge number(确认号码)。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k）时服务器 进入SYN_RECV状态。
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据。
2020-01-01 15.06.39.png
有人用了一个更生动形象的例子：在路上碰见老同学打招呼。
你挥手
老同学点头微笑，并向你招手
你点头微笑
四次挥手
简单来说，A,B两人打电话。
A：我没话说了。(主动断开A--B之间的通道连接，A进入FIN-WAIT-1状态)
B：别急，我还没说完，巴拉巴拉...。（B收到A的结束指令，向A发送ack，并继续发送数据，直到通道数据发完。B关闭等待状态CLOSE-WAIT，A进入FIN-WAIT-2状态）
B：我说完了。（告诉A，数据发完结束，可以结束。B进入LAST-ACK）
A：好的，知道了。（A再次确认结束。A进入TIME-WAIT-超时断开）
A，B断开。
屏幕快照 2020-01-01 15.19.06.png
SSL认证
安全套接字层 (SSL) 技术通过加密信息和提供鉴权，保护您的网站安全。一份 SSL 证书包括一个公共[密钥]和一个私用密钥。公共[密钥]用于加密信息，私用密钥用于解译加密的信息。浏览器指向一个安全域时，SSL同步确认服务器和客户端，并创建一种加密方式和一个唯一的会话密钥。它们可以启动一个保证消息的隐私性和完整性的安全会话。这里主要运用到一种方式数字证书。
数字证书
我们以百度的数字证书为例。可以在浏览器中点击百度网址前面的🔒，查看证书。发现证书里会包含签发者的机构名称，证书的有效时间，签名算法，公钥信息，指纹信息和指纹算法等，如下：
屏幕快照 2020-01-01 16.06.37.png
数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的，或者证书可以用来确认对方的身份。主要包含以下几个值：
◆证书的发布机构
指出是什么机构发布的这个证书，也就是指明这个证书是哪个公司创建的(只是创建证书，不是指证书的使用者)。对于上面的这个证书来说，就是指"GlobalSign nv-sa"这个机构。
◆证书的有效期
也就是证书的有效时间，或者说证书的使用期限。 过了有效期限，证书就会作废，不能使用了。
◆公钥
公钥是用来对消息进行加密的。
◆主题
这个证书是发布给谁的，或者说证书的所有者，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。 对于这里的证书来说，证书的所有者是baidu这个公司。
◆签名所使用的算法
就是指的这个数字证书的数字签名所使用的加密算法，这样就可以使用证书发布机构的证书里面的公钥，根据这个算法对指纹进行解密。指纹的加密结果就是数字签名。
◆指纹以及指纹算法
这个是用来保证证书的完整性的，也就是说确保证书没有被修改过。其原理就是在发布证书时，发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起，使用者在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值对得上，就说明证书没有被修改过，因为证书的内容被修改后，根据证书的内容计算的出的hash值(指纹)是会变化的。
当我们在浏览器地址栏键入www.baidu.com，服务端会返回一个数字证书（CA），浏览器会去识别这个证书的发布者是否可靠，会在操作系统受信任的发布机构中去寻找是否有该机构，上面就是GlobalSign nv-sa。如果没有则会提示该链接是不安全的。找到了这个机构的证书，应用程序就会去拿“GlobalSign nv-sa”证书上的公钥，用公钥进行对baidu证书上的指纹信息和指纹算法解密，然后用解密后的算法对证书的指纹信息进行计算，得出结果再和指纹信息进行比较，如果一致，则表明该证书没有被修改，是由权威认证机构认证的，属于该公司，是可信的。那么就可以建立安全的连接。
看到这里，是否觉得这个证书发布机构是块蛋糕？任何人想要在互联网上发布系统，都需要有一个数字证书。你没有，不好意思，大部分软件都会拒绝你。那我是不是可以注册个证书发布机构，自己给自己认证。小打小闹可以，在自己的机器上发布自签证书。并把证书加入到操作系统受信任的证书库里。但是别人的机器还是不识别，依旧会有报警。世界上只有少数机构具有此资质，而且监管很严格。同时他们也是和操作系统方有着密切的合作，所以在操作系统里会自带他们的认证。发布机构也不是来个需要就帮你认证，它需要证明“你就是你”，背调需要耗费人力财力，所以申请证书的价格也不少。
言归正传，回到我们开篇提到的内容。可以通过以下这个命令拿到证书，然后加入到jdk当中（运行之前，需要确认本机中安装的jdk路径，可以通过mvn -v来查看关联mvn的jdk版本）：
openssl s_client -connect application.com:443 -servername application.com -showcerts < /dev/null | openssl x509 -outform pem > server.pem
keytool -import -file C:\cascerts\firstCA.cert -alias firstCA -keystore myTrustStore
然后在我们的mvn 命令中传入证书信息，就可以愉快的请求到云上的应用了：
-Djavax.net.ssl.trustStore=./myTrustStore -Djavax.net.ssl.trustStorePassword=changeit
当然实际操作的时候还会遇到网络代理的问题，“javax.net.ssl.SSLHandshakeException: Received fatal alert: access_denied”,需要解决的是将请求的rest加上代理，可以设置System.setProperty("https.proxyHost","")。当然遇到的坑远不止这个：虽然我们在代码里指定了properties，但是请求的时候发现restTemplate并没有用它。通过以下方法的修改
image.png
至此完美的在Cloud外部跑通了case。
网友评论