随着业务的开展，系统架构从单体架构变为面向效劳架构，水平分层架构;再变为微效劳架构，
效劳网格，效劳与效劳间的交互越来越复杂，如何优雅的设计一个接口，需求思索哪些方面?特别是对公效劳(比如BFF)需求对外提供公网域名的接口，安全性怎样保证，我整理了我任务以来一些常见的措施以及详细如何去完成：
数据有效性校验合法性校验包括：常规性校验以及业务校验; 常规性校验：包括必填字段校验，长度校验，类型校验，格式校验等; 业务校验：依据实践业务而定，比如订单金额不能小于0等;
幂等设计所谓幂等，复杂地说，就是对接口的屡次调用所产生的结果和调用一次是分歧的。数据发作改动才需求做幂等，有些接口是自然保证幂等性的。
比如查询接口，有些对数据的修正是一个常量，并且无其他记载和操作，那也可以说是具有幂等性的。其他状况下，一切触及对数据的修正、形状的变更就都有必要避免重复性操作的发作。经过直接的完成接口的幂等性来避免重复操作所带来的影响。
又比如我们电商比较常见的加减GMV同一个音讯无论过去多少次结果都应该只加减一次，不然会招致金额错误甚至形成资损。
央求层面： 屡次执行的结果是分歧的 业务层面： 同一个用户不重复下单，商品不超卖，MQ不重复消费
幂等的本质是散布式锁的成绩，散布式锁正常可以经过redis或zookeeper完成;
在散布式环境下，锁定全局独一资源，使央求串行化，实践表现为互斥锁，避免重复，处置幂等
安全性1. 数据加密
我们知道数据在传输进程中是很容易被抓包的，假设直接传输比如http协议传输，那么数据在传输的进程中能够被任何人获取。
所以必须对数据停止加密，常见的做法是对敏感数据比如身份证号停止md5加密。如今主流的做法是运用https协议，在http和tcp之间添加一层数数据安全层(SSL层)，这一层担任数据的加密和解密。https如何配置和运用，大家翻阅我历史文章自行去研讨。
对称加密: 密钥在加密进程中和解密进程中是不变的，常见的算法有DES,AES;优点是加解密计算速度快;缺陷是数据传送前，效劳双方必须商定好密钥，假设一方密钥泄露，加密信息也就不安全了。
非对称加密: 密钥成对出现，一个密钥加密之后，由另外一个密钥来解密;私钥放在效劳端文件中，公钥可以发布给任何人运用;优点是比对称加密更安全，但是加解密的速度比对称加密慢多了，普遍运用的是RSA算法;
https的完成正好是结合了两种加密方式，整合了双方的优点，在安全性和功用方面都比较好。对称加密和非对称加密的代码完成，jdk提供了相关的工具类可以直接运用，本文不过多引见。
2. 数据签名
引见3种数据签名安全策略：摘要[KEY] , 签名[证书] , 签名+加密[证书]
安全策略 描画 安全级别 摘要[Key] 将数据和Key(自定义契约密码)组合后停止摘要 安全级别低，契约密钥安全性十分低。在契约密钥安全状况下能基本保障数据的不可窜改性。 签名[证书] 运用证书和非对称签名算法对数据停止签名 安全级别中，可以保障数据的不可窜改性和不可供认性，但是不能保障数据的私密性 签名-加密[证书] 运用证书和非对称算法对数据签名，运用一次一密的密钥和对称算法对数据停止加密 安全级别高，可以保障数据的不可窜改性和不可供认性，而且能保障数据的私密性。
秘密性(Confidentiality): 未经容许不许看
残缺性(Integrity) : 不许窜改
可用性(Availability) : 避免不可用
不可供认性(Non-Repudiation): 用户不能否认其行为
摘要[KEY]进程：将需求提交的数据经过某种方式组分解一个字符串，然后经过md5生成一段加密字符串，这段字符串就是数据包的签名，比如：
str：参数1={参数1}&参数2={参数2}&……&参数n={参数n}$key={用户密钥};
MD5.encrypt(str);
摘要[KEY]原理：Hash算法不可逆，并且计算结果具有独一性，在key 的隐私失掉保证的状况下，可以保证残缺性 摘要[KEY]缺陷：key的隐私性很难保证，明文传输
签名[证书]进程：客户端对明文做一个md5/SHA计算，对计算后的值经过私钥加密失掉密文，客户端将明文和密文发送给效劳端，效劳端对密文经过公钥解密失掉值A，同时效劳端对明文做一个md5/SHA计算失掉值B，比较值A与值B，相反得验证经过，可以保障不可篡性和不可供认性，但是不能保障数据的私密性(明文传输)
签名+加密[证书]进程：客户端生成一个随机字符串，作为password，然后把这个password经过B公钥加密生成密文C，把A明文经过password加密生成密文B， 同时把A明文做MD5/SHA计算后的值经过A私钥加密失掉签名D， 把密文B和密文C和签名D发给效劳端，效劳端经过私钥解密文C失掉password，然后经过password解密文B就可以失掉A明文，同时签名可以用来验证发送者是不是A，以及A发送的数据有没有被第三方修正过。
可以假定存在一个恶意的一方X，冒充了A，发送了密文B(password生成)，密文C效劳端收到数据后，依然可以正常解密失掉明文，但是却无法证明这个明文数据是A发送的还是恶意用户B发送的。签名D的含义就是A本人签名，效劳端可以验证。X由于没有A的私钥，这个签名它无法冒充，会被效劳端辨认出来。
3. 时间戳机制
数据经过了加密处置，酒店抓取到了数据也看不到真实数据;但是有不法者不关心真实数据，拿到数据后直接停止恶意央求，这个时分复杂的做法可以思索时间戳机制，在每次央求中参加以后时间，效劳端会将报文中的时间与系统以后时间做比对，看能否在一个固定的时间范围内比如5分钟，恶意伪造的数据是没法更改报文中时间的，超过5分钟就可以当作合法央求了。
伪代码如下：
long interval=5*60*1000；//超时时间
long clientTime=request.getparameter("clientTime");
long serverTime=System.currentTimeMillis();
if(serverTime-clientTime>interval){
return new Response("超过处置时长")
}
4. AppId机制
(责任编辑：admin)