July 2018

总体思路 这个涉及到两个方面问题： 一个是接口访问认证问题,主要解决谁可以使用接口（用户登录验证、来路验证） 一个是数据数据传输安全,主要解决接口数据被监听（HTTPS安全传输、敏感内容加密、数字签名） 用户身份验证：Token与Session 开放接口Api服务其实就是客户端与服务端无状态交互的一种形式，这有点类似REST(Representational State Transfer)风格。 普通网站应用一般使用session进行登录用户信息的存储和验证（有状态），而开放接口服务/REST资源请求则使用Token进行登录用户信息的验证（无状态）。Token更像是一个精简版的session。Session主要用于保持会话信息，会在客户端保存一份cookie来保持用户会话有效性，而Token则只用于登录用户的身份鉴权。所以在移动端使用Token会比使用Session更加简易并且有更高的安全性，同时也更加符合RESTful中无状态的定义。 Token交互流程 客户端通过登录请求提交用户名和密码，服务端验证通过后生成一个Token与该用户进行关联，并将Token返回给客户端。 客户端在接下来的请求中都会携带Token，服务端通过解析Token检查登录状态。 当用户退出登录、其他终端登录同一账号、长时间未进行操作时Token会失效，这时用户需要重新登录。 Token生成原理 服务端生成的Token一般为随机的非重复字符串，根据应用对安全性的不同要求，会将其添加时间戳（通过时间判断Token是否被盗用）或url签名（通过请求地址判断Token是否被盗用）后加密进行传输。一般Token内容包含有：用户名/appid，密码/appsecret, 授权url，用户自定义token(用户自定义签名)，时间戳，有效期时长(秒), 系统签名(sign)等。 Api接口服务调用流程： 1. 首先要获取全局唯一的接口调用凭据(access_token)。该过程务必使用https安全传输协议，否则被拦截监听了，用户名和密码等重要数据就都泄漏了。 […]

常用认证方式 在之前的文章REST API 安全设计指南与使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中，[译]web权限验证方法说明中也详细介绍，一般基于REST API 安全设计常用方式有： HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic

REST API 安全设计指南   REST API 安全设计指南。REST的全称是REpresentational State Transfer，它利用传统Web特点，提出提出一个既适于客户端应用又适于服务端的应用的、统一架构，极大程度上统一及简化了网站架构设计。 目前在三种主流的Web服务实现方案中，REST模式服务相比复杂的SOAP和XML-RPC对比来讲，更加简洁，越来越多的web服务开始使用REST设计并实现。但其缺少安全特性，《REST API 安全设计指南》就是一个REST API安全设计的指南，权当抛砖引玉，推荐网站后台设计及网站架构师们阅读。 文章目录 1，REST API 简介 2，身份认证 2.1 HTTP

作者：胡建华 中国移动苏州研发中心，IT支撑产品部，技术研究员 主要从事集中化系统架构设计，以及数据保护（存储、备份、云盘）、智能运维相关领域的技术研究和开发工作。 1、BAIOPS-业务智能运维 智能运维（AIOps-Algorithmic IT Operations基于算法的IT运维）是人工智能技术在IT运维领域的运用，引用Gartner 的报告的一段话“到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，远远高于今天的10%”，最近2-3年智能运维的概念随处可见，各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想，同时也有人谈AI色变，觉得人工智能只是一个愿景，要落地很难。其实AI已经不是一个新的概念了，百度、微软、谷歌等公司早就在10几年前开始自己的人工智能布局了，到现在均已成为人工智能行业的领跑者了。 话不多说，人工智能那么强大，应用场景十分的广泛，当然也包括运维领域，而且面向业务的运维更是运维发展的热点趋势，下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。   2、传统运维-痛之又痛   传统的运维中，存在着诸多痛点： （1）被动低效的运维难以保证业务连续性 运维人员往往扮演着事后“救火”的角色，待事故发生后才去处理； 数据分散在多处，出了故障无法快速修复，业务连续性难以有效保障； 随着业务复杂性不断提高，人工运维的成本呈指数级增长。 （2）缺乏统一的运维监控体系和技术工具 针对不同运维实体的烟囱式的运维工具，功能重叠、难以整合； 运维的自动化程度偏低，运维脚本泛滥，层次化、模块化程度不足；

本文是学习大型分布式网站架构的技术总结，对构建一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。 文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 大型分布式网站架构技术 大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。