Month 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安全传输协议，否则被拦截监听了，用户名和密码等重要数据就都泄漏了。 具体过程： a. 客户端向服务端通过https协议发送请求，参数包含用户名、密码、请求类型等 b. 服务端接到请求后，验证用户信息是否正确，如果正确，返回access_token和expires。否则返回errorcode和errmsg。 c. 服务端access_token可以存储在session或者redis等内存数据库中，键名(key)为user_id,键值为access_token。 d. 客户端获得access_token后，保存到file或redis等内存数据库中。不推荐保存到session或数据库中，保存到session数据容易丢失，保存到数据库因为涉及IO读写，性能较低。 2. 通过RESTful风格的资源请求格式调用接口，如： https://api.weixin.qq.com/cgi-bin/user/info?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN 正常情况下，服务端会返回JSON数据包给调用者，成功则返回包含业务数据内容的JSON数据包，失败则返回包含errcode和errmsg的JSON数据包 对于敏感的api接口，需使用https协议 http叫超文本传输协议，使用TCP端口80，默认情况下数据是明文传送的，数据可以通过抓包工具捕获到，因此在interner上，有些比较重要的站点的http服务器需要使用PKI（公钥基础结构）技术来对数据加密！这也就是https了； https叫安全的超文本传输协议，使用TCP端口443，他的数据会用PKI中的公钥进行加密，这样抓包工具捕获到的数据包也没有办法看包中的内容，因为他没有密钥，当然篡改也就没有什么意义了，安全性大大提高，要解密数据的话就要用到PKI中的私钥。所以一些安全性比较高的网站如：网上银行，电子商务网站都需要用https访问！ 微信access_token设计的原理解析 1. appid：接口身份证号。 2.…

常用认证方式 在之前的文章REST API 安全设计指南与使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中，[译]web权限验证方法说明中也详细介绍，一般基于REST API 安全设计常用方式有： HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic YWRtaW46YWRtaW4= 由于HTTP协议是无状态的，所有每次请求都得带上身份信息，基于Http basic验证就是简单的将用户名和密码base64编码放到header中，一般需要HTTPS,安全性较低，实现的方式可以基于代码实现也可以基于web容器配置apache,nginx等web服务器即可实现。 HTTP Digest 摘要认证 digest authentication,服务器端以nonce进行质询，客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生的response信息进行认证的方式。 ※ 不包含密码的明文传递 摘要认证步骤： 1. 客户端访问一个受http摘要认证保护的资源。 2. 服务器返回401状态以及nonce等信息，要求客户端进行认证。 HTTP 401 Unauthorized WWW-Authenticate: Digest…

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 Basic 2.2 API KEY 2.3 Oauth1.0a或者Oauth2 2.4 JWT 3 授权 4 URL过滤 5 重要功能加密传输 6 速率限制 7 错误处理 8 重要ID不透明处理…

作者：胡建华 中国移动苏州研发中心，IT支撑产品部，技术研究员 主要从事集中化系统架构设计，以及数据保护（存储、备份、云盘）、智能运维相关领域的技术研究和开发工作。 1、BAIOPS-业务智能运维 智能运维（AIOps-Algorithmic IT Operations基于算法的IT运维）是人工智能技术在IT运维领域的运用，引用Gartner 的报告的一段话“到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，远远高于今天的10%”，最近2-3年智能运维的概念随处可见，各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想，同时也有人谈AI色变，觉得人工智能只是一个愿景，要落地很难。其实AI已经不是一个新的概念了，百度、微软、谷歌等公司早就在10几年前开始自己的人工智能布局了，到现在均已成为人工智能行业的领跑者了。 话不多说，人工智能那么强大，应用场景十分的广泛，当然也包括运维领域，而且面向业务的运维更是运维发展的热点趋势，下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。   2、传统运维-痛之又痛   传统的运维中，存在着诸多痛点： （1）被动低效的运维难以保证业务连续性 运维人员往往扮演着事后“救火”的角色，待事故发生后才去处理； 数据分散在多处，出了故障无法快速修复，业务连续性难以有效保障； 随着业务复杂性不断提高，人工运维的成本呈指数级增长。 （2）缺乏统一的运维监控体系和技术工具 针对不同运维实体的烟囱式的运维工具，功能重叠、难以整合； 运维的自动化程度偏低，运维脚本泛滥，层次化、模块化程度不足； 监控、运维、告警平台林立，各成体系，缺乏统一化体系。 （3）海量的运维数据的价值无法充分挖掘 传统运维系统收集了大量的运维数据，但是却缺乏有效的手段加以分析和利用； 运维数据的利用仅限于简单的可视化和浅度的分析上，缺乏纵向数据的关联挖掘，无法快速定位故障根因； 固定式的阈值告警造成了大量的误判和漏判，而且人工调整阈值的方式也比较费时费力。 （4）缺乏全方位端到端的运维监控手段 大部分的运维监控仅停留在针对主机、网络的层面，忽略了业务层面的识别手段，故障的发生无法从最直接的业务层面得以发现，产生预警； 性能管理大多停留在服务单应用性能的管理和分析上，无法提供端到端的掌控。   3、业务智能运维的切入点 针对上述这些传统运维中存在的痛点，智能化的运维出现必定具有划时代的意义，智能运维系统的设计可以从如下几方面进行展开思考： （1）面向业务维度实现异常检测 业务运维是运维的大趋势，需从最复杂的业务维度入手，根据业务维度的指标（如PV、响应时间、错误率、GC等）上的异动进行异常检测，提前预警； （2）提供业务全局关系视图 业务应用维度的复杂性是运维过程中最高的，往往是二线和三线运维之间界限最模糊的区域，所以智能运维可以先解决的就是向用户提供全面、清晰的业务关系视图，让运维人员对业务应用的掌控得心应手； （3）KPI可视化与下钻定位 KPI指标可以通过丰富的可视化手段展示给运维人员，业务系统的故障可以清晰的体现在可视化终端，同时支持详细的下钻手段，直至定位到发生故障的环节，甚至代码段； （4）采用动态阈值思想的异常检测 避免传统固定阈值告警的弊端，引入机器学习算法来进行阈值动态化的异常检测效果； （5）重视故障的全流程管理…

本文是学习大型分布式网站架构的技术总结，对构建一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。 文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 大型分布式网站架构技术 大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。 敏捷性：随需应变，快速响应。 大型网站架构模式 如上图是大型网站的架构模式： 分层：一般可分为应用层、服务层、数据层、管理层与分析层。 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方。一般指：请求——响应——通知模式。 冗余：增加副本，提高可用性、安全性与性能。 安全：对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。 自动化：将重复的、不需要人工参与的事情，通过工具的方式，使用机器完成。 敏捷性：积极接受需求变更，快速响应业务发展需求。 高性能架构 高性能的架构是以用户为中心，提供快速的网页访问体验，主要参数有较短的响应时间、较大的并发处理能力、较高的吞吐量与稳定的性能参数。 可分为前端优化、浏览器优化、应用层优化、代码层优化与存储层优化： 前端优化：网站业务逻辑之前的部分。 浏览器优化：减少 HTTP 请求数，使用浏览器缓存，启用压缩，CSS…