引言

在当今快速演变的技术场景中，服务设计不仅仅是遵循通用的设计规范和最佳实践的问题，它更深层次地触及到如何在满足这些标准的同时，确保服务能够灵活适应未来的变化、满足用户的期望。本篇文章旨在探讨在遵循通用设计规范之外，服务设计过程中需要考虑的关键因素。希望经过我们一系列的分享，能和大家一起讨论如何将API设计的易对接，易理解和易扩展。

系统介绍

 京东企业业务VOP(智采)：以API形式为客户提供京东供应链能力；VOP提供上百个标准API服务，为上千家客户搭建自采商城提供底层能力。

服务设计tips

1、服务路径和模块

2、服务请求方式

对于大部分服务来说，应支持ajax请求，并且指定固定的数据格式(JSON/XML等)，既方便后续扩展，又能支持业内绝大部分的客户业务处理。但对于部分特殊场景的服务，如收银台，登录/登出等接口，则需要非ajax请求，由服务端进行后续的转发跳转处理。

3、服务出入参

    {
        "success": true，
        "resultMessage": "success"，
        "resultCode": "0000"，
        "result": {}
    }

4、服务内业务处理的一些建议

5、异常处理

6、服务的强弱依赖

在构建一个复杂的对外服务时通常会依赖多个外部接口。对于这些依赖，我们可以将它们分为两类：强依赖和弱依赖。强依赖的接口是服务运行不可或缺的部分，如果这类接口出现异常，我们通常采用的策略是短路处理，即立即中断当前操作，以避免进一步的错误传播或数据不一致。

另一方面，对于弱依赖的接口，它们对主流程的影响相对较小，可以容忍一定程度的异常或失败。在这种情况下，如果弱依赖接口发生异常，我们可以选择忽略这些异常，并继续执行服务的核心流程。同时，为了确保服务的稳定性和问题的可追踪性，我们会实施业务告警机制，以便及时发现并处理这些异常情况。这种做法旨在保证服务的整体可用性，同时确保问题不会在无人知晓的情况下被忽略。

7、服务的监控和日志记录

8、合理设置降级点

在构建复杂的服务时，特别是在分布式系统和微服务架构的背景下，我们一般需要依赖很多第三方服务或数据。在这种情况下，服务降级策略就成为确保整体系统稳定性的关键。 服务降级主要是指在某些服务模块遇到性能瓶颈或者故障时，主动地减少或关闭这些组件的某些功能，以此来保障整个系统的核心运作。

为了有效实施服务降级，需要在开发和设计过程中识别到潜在的风险点，并据此划分出服务中的 关键与非关键模块。在非关键模块的代码层面嵌入降级逻辑，让我们可以在出现问题时，手动或自动执行降级操作，从而确保关键服务的持续可用性。这种设计不仅有助于提升系统的鲁棒性，也可以有效地减少系统故障时对用户的影响。

9、处理过时服务

每一个系统都会出现很多初期简单设计、只满足简单业务场景的服务，随着业务的发展，初期设计的很多服务将不再能满足新的业务场景，在原服务无法扩展的情况下，我们一般会增加新的服务(需要能覆盖旧服务的能力)，久而久之，就会产生很多几乎无客户使用的过时服务，有可能会产生影响代码问题排查、触发业务场景漏洞等问题，对于这样的服务，我们需要有两种处理办法:

10、不要相信任何调用方和依赖的第三方

在服务设计和编程过程中，对于所有依赖的第三方的服务都要保持不信任的前提，对其返回的数据、服务的超时时间、异常的返回等均需要细致处理，要考虑每一个可能出现的问题点，防止某一个依赖的服务出现问题进而影响全局。

同样的，也不能信任调用方。无论事先如何保证或者规约，都无法保证调用方的调用行为符合预期，所以 我们在服务上线前就需要考虑和 构建多种防御机制。这包括但不限于：实施有效的限流措施、进行严格的输入验证、以及设置精细的权限控制等。 通过这样的设计，我们不仅能够提升服务的稳定性和安全性，还能确保在面对不可预测的外部因素时，我们的系统能够保持弹性和韧性。

保障服务和信息安全的措施

(1)敏感字段

在B2B场景中，企业对于用户敏感数据的要求较高，比如手机号，用户名，住址等信息，这就要求服务提供方在接口出参时对于这些数据进行加密处理，加密这些信息可以防止在数据传输过程中被未经授权的第三方截取和读取，从而保护客户和企业的隐私和利益。

加密可以在不同的层面上实施：

在使用敏感字段加密时，需要注意以下几点：

(2)系统准入

部分对系统安全要求较高的客户，会要求服务方对非法的调用方进行拦截，防止非法第三方在获取到身份信息之后使用客户身份进行调用进而产生资损或更多的数据泄露。面对这种情况，我们可以使用设置IP黑白名单的方式来进行拦截，限制某个身份标识只能是指定的ip来访问或指定的ip不能访问。

IP白名单:只有在白名单中的IP地址被允许访问系统或接口。不在列表中的所有IP地址都会被拒绝。 优点：提供了别的安全性，在客户维度下，只有预先批准的IP地址可以访问，其余IP均不能以该客户身份进行访问。可以有效防止未授权的访问尝试，在某些特定场景下，甚至可以取消授权校验，IP即代表客户身份。 缺点：管理起来可能比较繁琐，尤其是当合法用户的IP地址经常变化时。对于使用动态IP地址的用户不太友好。 适用场景：适用于访问者数量有限且IP地址固定或变化不大的环境。



IP黑名单:在黑名单中的IP地址不被允许访问系统或接口。不在列表中的IP地址则可以访问。 优点：简单易于管理，只需要列出已知的恶意IP地址。对于大多数合法用户来说，不会影响他们的访问。 缺点：安全性较低，因为新的未知攻击者仍然可以访问系统。恶意用户可以通过更换IP地址来绕过黑名单控制。适用场景较少，目前VOP平台尚未有客户选择此种IP校验类型。 适用场景：适用于开放性较高的环境，或者作为其他安全措施的补充。

(3)接口出入参防篡改

确保通过接口发送的数据在传输过程中未被修改。这对于保障调用双方数据的完整性和安全性至关重要，常用的防篡改方法有以下几种 :

a. 使用HTTPS

确保所有数据传输通过HTTPS进行，这样数据在传输过程中会被加密，从而降低被截取和篡改的风险。

b. 数字签名

在发送数据前，调用方使用数字签名对数据进行签名，接收方可以使用相应的公钥验证签名，以确保数据自签名以来未被修改。

数字签名的步骤如下：

发送方使用私钥对数据（可以是数据的哈希值或直接将参数按规则拼接成字符串）进行签名。

发送方将数据和签名一起发送给接收方。

接收方收到数据后，使用发送方的公钥验证签名。

如果签名验证成功，说明数据未被篡改；如果失败，说明数据在传输过程中可能遭到篡改。

c. 消息认证码（MAC）

与数字签名类似，消息认证码（MAC）是一种确保消息完整性的技术，它使用一个密钥和消息内容生成一个MAC值。接收方使用 相同的密钥生成MAC值，并与发送方提供的MAC值进行比较。

d.使用API密钥和时间戳

结合API密钥和时间戳可以提供另一层安全性。时间戳可以防止 重放攻击，API密钥则确保只有授权的用户可以发送请求。

(4)出入参加解密

出入参加解密是指在客户端发送请求到服务器（入参解密）和服务器返回响应到客户端（出参加密）的过程中，对数据进行加密和解密的操作。这样做可以保护数据在传输过程中的安全性，防止敏感信息被窃取或篡改 。

出入参要求全是加密后的数据，这种需求一般来自银行或者国央企等十分看重数据安全的客户。作为接口数据安全的可选项，并不适用于全部客户，而且要求数据密文传输的客户，一般都会指定数据的加密方式，有可能是业内通用的加密方式，也有可能是客户内部自定义的一个jar包。

关于后者，我们搭建了一个可以加载不同客户的加密SDK的 ECI平台，通过这个平台，将每个客户提供的加密SDK隔离加载，确保不会因为某个客户SDK出现问题而影响全部客户;在平台上传客户的SDK并加载完成之后，会对外提供一个服务接口，该接口支持客户维度的加密和解密两种操作。我们只需要按客户维度配置该客户对应的加解密方法，在拦截器层面进行统一处理加解密操作即可，对实际业务代码完全无侵入。

伪代码示例:

/**
 * @description 指定客户接口出入参加解密拦截器
 */@Servicepublic class EncryptInterceptor extends HandlerInterceptorAdapter {
        //请求进入，业务处理前解密
	@Override
	public boolean preHandle(HttpServletRequest request， HttpServletResponse response， Object handler) throws Exception {
		if(!(request instanceof  DecryptionRequestWrapper)){
			return true;
		}
		//获取客户授权信息，获取到当前客户身份
		try {
		    //判断该客户是否开启接口加解密
                    //组织参数，获取原始入参，进行解密操作
                    //解密完成后，将解密得到的参数全部加入到request的参数内
                    //继续向下进行
			return true;
		} catch (Throwable throwable){
		    //异常处理
		}
	}
        //返回前加密
	@Override
	public void postHandle(HttpServletRequest request，HttpServletResponse response， Object handler，			ModelAndView modelAndView) throws Exception {
		
		//获取客户身份标识
		try{
		    //判断该客户是否开启接口加解密
	            //调用原始的 postHandle 方法，让响应数据被写入包装类的输出流
		    //调用加密方法，获取加密后数据
		    //将加密后的数据写回响应
		}catch (Throwable throwable){
		    //异常处理
		}
	}}

结语

构建一个健壮的服务和系统不仅是技术领域专业人士的终极追求，也是确保我们能够在面对未来不断演变的业务需求和技术挑战时保持竞争力的关键。在遵守广泛认可的设计规范之外，我们必须进一步探索和优化，确保我们的服务不仅可以全面覆盖各种业务场景，还要在安全性、可扩展性以及可伸缩性和降级能力方面表现出色。

这种追求不仅要求我们在设计之初就深入考虑潜在的风险和挑战，还要求我们在整个开发过程中对服务进行持续评估和优化。这样的系统将成为支持企业业务持续增长和创新的坚实基础，帮助我们在不断变化的技术和业务环境中保持领先!

读完此篇，加入光荣的进化吧!