背景随着业务的发展，系统架构从单一的架构转变为面向服务的架构，水平分层的架构；再到一个微服务架构，一个服务网格，服务之间的交互越来越复杂。如何优雅的设计一个界面，需要考虑哪些方面？尤其是对于需要对外提供域名接口的公共服务（比如BFF），如何保证安全，我整理了一些工作以来常见的Measures以及实现方法：数据有效性校验。合法性验证包括：日常验证和业务验证；常规校验：包括强制字段校验、长度校验、类型校验、格式校验校验等；业务验证：以实际业务为准，如订单金额不能小于0等；幂等设计所谓幂等，简单的说就是多次调用接口的结果与一次调用的结果是一致的。只有在数据发生变化时才需要幂等，有些接口天生就是幂等的。比如查询接口，有些数据修改是常量，没有其他记录和操作，也可以说是幂等的。在其他情况下，所有数据修改和状态更改都是必要的，以防止发生重复操作。通过间接实现接口的幂等性来防止重复操作的影响。再比如我们电商中常见的GMV加减法，无论同一条消息来多少次，结果都应该只加减一次，否则会导致金额错误甚至资金损失。请求级别：多次执行结果一致。业务层面：同一用户不重复下单，商品不超卖，MQ不重复消费。动物园管理员实施；在分布式环境下，锁定唯一的全局资源，序列化请求，实际上起到互斥锁的作用，防止重复，解决幂等安全1.数据加密我们知道，数据在传输过程中很容易被窃取对于抓包来说，如果数据是直接传输如http协议，则数据在传输过程中可能被任何人获取。因此，必须对数据进行加密。通常的做法是使用md5加密敏感数据，例如ID号。目前主流的做法是利用https协议在http和tcp之间增加一个数据安全层（SSL层），负责数据的加密和解密。如何配置和使用https，大家可以看我的历史文章自行研究。对称加密：加密和解密过程中密钥不变。常见的算法包括DES和AES；优点是加解密的计算速度快。缺点是在数据传输之前，双方必须就密钥达成一致。如果密钥泄露，则加密信息不安全。非对称加密：密钥成对出现，一个密钥被加密，然后被另一个密钥解密；私钥放在服务器文件中，公钥可以发布给任何人；优点是比对称加密更安全。但是加解密的速度比对称加密慢很多，广泛使用RSA算法；https的实现恰好结合了两种加密方式，综合了双方的优点，在安全性和性能上都更胜一筹。对于对称加密和非对称加密的代码实现，jdk提供了相关工具，可以直接使用，本文不再过多介绍。2、数据签名引入3种数据签名安全策略：抽象[KEY]、签名[证书]、签名+加密[证书]低，合约密钥安全性非常低。在合约密钥安全的情况下，基本可以保证数据的不可篡改。签名[证书]使用证书和非对称签名算法对数据进行签名在安全级别上，可以保证数据的不可篡改和不可抵赖性，但不能保证数据的隐私性。签名-加密【证书】使用证书和非对称算法对数据进行签名，使用一次性密钥和对称算法对数据进行加密，安全级别高，可以保证数据的不可篡改和不可抵赖性，可以保证数据的隐私。保密性：未经许可不得查看完整性：不得篡改可用性：防止不可用不可否认性：用户不能否认自己的行为加密后的字符串是通过md5生成的，是数据包的签名，例如：str:parameter1={parameter1}¶meter2={parameter2}&...¶metern={parametern}$key={用户密钥};MD5.encrypt(str);总结【KEY】原理：Hash算法不可逆，计算结果唯一，在保证密钥私密性的情况下，可以保证完整性。总结【KEY】缺陷：密钥的私密性难以保证，明文传输签名【证书】过程：客户端对明文进行md5/SHA计算，得到后用私钥加密计算出的值密文，客户端将明文和密文发送给服务器。服务器用公钥解密密文得到值A，同时服务器对明文进行md5/SHA计算得到值B，将值A与值B进行比较，相同验证通过，可以保证不可篡改和不可抵赖性，但不能保证数据的私密性（明文传输）签名+加密【证书】过程：客户端生成一个随机字符串作为密码，然后使用这个password密文C是用B的公钥加密生成的，密文B是用password加密A的明文生成的。同时用A的私钥对A的明文MD5/SHA计算值进行加密得到签名D，加密密文B和密文C。并将签名D发送给服务器，服务器通过私钥解密文本C得到密码，再通过密码解密文本B得到明文A，签名可以用来验证发送者是否是A，A发送的数据是否被第三方修改过。可以假设有恶意方X冒充A发送密文B（由密码生成）。密文C服务器收到数据后，仍然可以正常解密明文，但不能证明明文数据是A发送的。是恶意用户B发送的。签名D的意思是A自己签名，并且服务器可以验证它。由于X没有A的私钥，这个签名无法被冒充，会被服务器识别。Encryption-Signature3.时间戳机制数据加密，酒店即使抓包也看不到真实数据；但也有不法分子不关心真实数据，拿到数据后直接进行恶意请求。这时候简单的方法可以考虑时间戳机制，在每次请求中加上当前时间，服务端会把报文中的时间和当前系统时间进行比较，看是否在固定的时间范围内，比如5分钟。恶意伪造的数据，如果没有办法更改报文中的时间，超过5分钟就可以认定为非法请求。伪代码如下：longinterval=5*60*1000；//超时时间longclientTime=request.getparameter("clientTime");longserverTime=System.currentTimeMillis();if(serverTime-clientTime>interval){returnnewResponse("超出处理时间")}4.AppId机制大多数网站都需要用户名和密码才能登录，这其实是一种安全机制；相应的服务也可以使用这种机制。不是每个人都可以调用它。在调用服务之前，首先要申请一个唯一的appid，提供相关的key，调用接口时需要提供appid+key信息，服务端会进行验证。appid使用字母、数字、特殊符号等随机生成，生成的唯一appid取决于系统实际是否要求全局唯一；不管是否全局唯一，最好有以下属性：趋势递增：这样在保存数据库的时候，索引的性能更好信息安全：随机生成，不连续，容易被成立。生成全局唯一Id的常用方法有雪花法等，上面的雪花图描述了序列号的二进制结构。第一位不用，一直为0，表示正整数；接下来的41位代表时间戳，精确到毫秒。为了节省空间，这个时间戳可以定义为从某个时间点开始经过的毫秒数（Java默认为1970-01-0100:00:00）。接下来的10位用于识别工作机器。如果出现跨IDC的情况，这10位可以分为两部分，一部分用于标识IDC，另一部分用于标识服务器；最后12位为序号，自增。snowflake的核心思想是64bit的合理分配，但不一定要严格按照上图所示的划分方式。如果机器比较少，可以适当缩短机器id的长度，留给序列号使用。5.黑名单机制如果该appid进行了多次非法操作，或者有专门的黑名单系统，经过分析，该appid将直接被列入黑名单，所有请求直接返回错误码；我们可以为每个appid设置一个状态，比如：初始化状态、正常状态、黑屏状态、关闭状态等；或者我们直接通过分布式配置中心保存黑名单名单，每次检查是否在名单中；流算法包括：令牌桶限流、漏桶限流、计数器限流；令牌桶限流令牌桶算法的原理是系统按照一定的速率向桶中放入令牌，满了就丢弃令牌；当有请求到来时，先从桶中取出令牌。如果能够获取到token，则可以继续请求，否则会等待或拒绝服务；令牌桶允许一定程度的突发流量，只要有令牌就可以处理，支持一次取多个令牌；漏桶限流漏桶算法的原理是以固定恒定速率流出请求，流入请求速率任意。当请求数超过桶的容量时，新的请求等待或拒绝服务；可见，漏桶算法可以强制限制数据的传输速度；计数器限流计数器是一种比较简单粗暴的算法，主要用于限制并发总数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只需要一定时间，如果总请求数超过设定的阈值，就会进行限流；基于上述算法的实现方式，Guava提供了基于令牌桶算法的RateLimiter工具类：RateLimiterrateLimiter=RateLimiter.create(5)；上面的代码表示一秒时钟只允许处理五个并发请求。以上方法只能用于单应用请求限流，不能用于全局限流；这时候就需要分布式限流，可以基于redis+lua实现；综上所述，无论接口是设计还是开发，如果不是特别迫切的需求，大家可以多想想，这样你的系统才会更加稳定，上线和测试过程中的bug也会少一些，而且从个人提升??的角度来说，多想总是好事。很多时候大家都在抱怨：唉，我公司小，学校差。这种环境无法生长。傻瓜，大多数时候高手都是同路而来，只是每个人对同一件事的态度不同，时间长了结果也就不一样了。好吧，现在每个人都应该上班了。值班熬夜，还在大促现场（文章是周末写的，现在写个总结）。我是敖丙。知道的越多，不知道的越多，我们下期再见。
