IT瘾设计推荐

谈谈国内前端的三大怪啖

Tue, 15 Aug 2023 00:57:00 CST

因为工作的原因，我和一些国外的工程师们有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。

今天聊三个事情：

小程序
微前端
模块加载

小程序

每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。

“ 我们为什么需要小程序？”

第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着。

于是，当我们在有一次交流中，他问出了我这个问题： 我们为什么需要小程序？

说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时候所带来的便利和体验等等。总之，在我看来并不够深刻的见解。

即便到现在为止，每次当我使用小程序的时候，依旧会复现这个问题。在 ChatGPT 11 月份出来的时候，我也问了它这个很有国内特色的问题：

看起来它回答的还算不错，至少我想如果它来糊弄那些老外，应该会比我做的更好些。

但如果扪心自问，单从技术上来讲。以上这些事情，一定是有其他方案能解决的。

所以从某种程度上来看，这更像是一场截胡的商业案例：

应用市场

全世界的互联网人都知道应用市场是非常有价值的事情，可以说操作系统最值钱的部分就在于他们构建了自己的应用市场。

只要应用在这里注册发行，雁过拔毛，这家公司就是互联网世界里的统治阶级，规则的制定者。

反之则需要受制于人，APP 做的再大，也只是应用市场里的一个应用，做的好与坏还得让应用商店的评判。

另外，不得不承认的是，一个庞大如苹果谷歌这样的公司，他们的应用商店对于普通国内开发者来说，确实是有门槛的。

在国内海量的 APP 需求来临之前，能否提供一个更低成本的解决方案，来消化这些公司的投资？

毕竟不是所有的小企业都需要 APP，其实他们大部分需求 Web 就可以解决，但是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样…)

那做操作系统？太不容易，那么多人都溺死在水里了，这水太深。

那有没有一种办法可以既能构建生态，又有 APP 的心智，还能给入驻企业提供流量？

于是，在 19 年夏天，深圳滨海大厦下的软件展业基地里，每天都在轮番播放着，做 XX小程序，拥抱下一个风口…

全新体验心智

小程序用起来挺方便的。

你有没有想过，这些美妙感觉的具体都来自哪些？以及这些真的是 Web 技术本身无法提供的吗？

靠谱感，每个小程序都有约束和规范，于是你可以将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的作品，相对于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序更加的有分量和靠谱。
安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时可能丢失网页。你不会因为网速白屏而感到焦虑，尽管网络差的时候，你的 KFC 依旧下不了单
沉浸感，我不知道是否打开网页时顶部黑黑的状态栏是故意留下的，还是不小心的… 这些限制都让用户非常强烈的意识到这是一个网页而不是 APP，而小程序中虽然上面也存在一个空间的空白，但是却可以被更加沉浸的主题色和氛围图替代。网页这个需求做不了？我不信。

H5	小程序

顺滑感，得益于 Native 的容器实现，小程序在所有的视图切换时，都可以表现出于原生应用一样的顺滑感。其实这个问题才是在很多 Hybrid 应用中，主要想借助客户端来处理和解决的问题。类似容器预开、容器切换等技术是可以解决相关问题的，只是还没有一个标准。

我这里没有提性能，说实话我不认为性能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论范畴）。作为普通用户，我们感受到的只是离线加载下带来的顺滑而已。

而上述提到的许多优势，这对于一个高品质的 Web 应用来说是可以做得到的，但注意这里是高品质的 Web 应用。而这种“高品质”在小程序这里，只是入驻门槛而已。

心智，这个词，听起来很黑话，但却很恰当。当小程序通过长期这样的筛选，所沉淀出来一批这样品质的应用时。就会让每个用户即便在还没打开一个新的小程序之前，也有不错体验的心理预期。这就是心智，一种感觉跟 Web 不一样，跟 APP 有点像的心智。

打造心智，这件事情好像就是国内互联网企业最擅长做的事情，总是能从一些细微的差别中开辟一条独立的领域，然后不断强化灌输本来就不大的差异，等流量起来再去捞钱变现。

我总是感觉现在的互利网充斥着如何赚钱的想法，好像永远赚不够。“赚钱”这个事情，在这些公司眼里就是圈人圈地抢资源，看看谁先占得先机，别人有的我也得有，这好像是最重要的事情。

很少有企业在思考如何创造些没有的市场，创造些真正对技术发展有贡献，对社会发展有推动作用的事情。所以在国内互联网圈也充斥着一种奇怪的价值观，有技术的不一定比赚过钱的受待见。

管你是 PHP 还是 GO，管你是在做游戏还是直播带货，只要赚到钱就是高人。并且端的是理所应当、理直气壮，有些老板甚至把拍摄满屋子的程序员为自己打工作为一种乐趣。什么情怀、什么优雅、什么愿景，人生就俩字：搞钱。

不是故意高雅，赚钱这件事情本身不寒碜，只是在已经赚到盆满钵满、一家独大的时候还在只是想着赚更多的钱，好像赚钱的目的就是为了赚钱一样，这就有点不合适。企业到一定程度是要有社会责任的，龙头企业每一个决定和举措，都有会影响接下来的几年里这个行业的价值观走向。

当然也不是完全没有好格局的企业，我非常珍惜每一个值得尊重的国内企业，来自一个蔚来车主。

小程序在商业上固然是成功的，但吃的红利可以说还是来自网页到应用的心智变革。将本来流向 APP 的红利，截在了小程序生态里。

但对于技术生态的发展却是带来了无数条新的岔路，小程序的玩法就决定了它必须生长在某个巨型应用里面，不论是用户数据获取、还是 API 的调用，其实都是取决于应用容器的标准规范。

不同公司和应用之间则必然会产生差异，并且这种差异是墒增式的差异，只会随着时间的推移越变越大。如果每个企业都只关注到自己业务的增长，无外部约束的话，企业必然会根据自己的业务发展和政策需要，选择成本较低的调整 API，甚至会故意制造一些壁垒来增加这种差异。

小程序，应该是浏览器与操作系统的融合，这本应该是推动这两项技术操刀解决的事情。

微前端

qiankun、wujie、single-spa 是近两年火遍前端的技术方案，同样一个问题：我们为什么需要微前端？

我不确定是否每个在使用这项技术的前端都想清楚了这个问题，但至少在我面试过的候选人中，我很少遇到对自己项目中已经在使用的微前端，有很深的思考和理解的人。

先说下我的看法：

微前端，重在解决项目管理而不在用户体验。
微前端，解决不了该优化和需要规范的问题。
微前端，在挽救没想清楚 MPA 的 SPA 项目。

没有万能银弹

银色子弹（英文：Silver Bullet），或者称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱魔功效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。

所有技术的发展都是建立在前一项技术的基础之上，但技术依赖的选择过程中一定需要保留第一性原理的意识。

当 React、Vue 兴起，当打包技术(Webpack) 兴起，当网页应用(SPA) 兴起，这些杰出的技术突破都在不同场景和领域中给行业提供了新的思路、新的方案。

不知从何时开始，前端除了 div 竟说不出其他的标签(还有说 View 的)，项目中再也不会考虑给一个通用的 class 解决通用样式问题。

不知从何时开始，有没有权限需要等到 API 请求过后才知道，没有权限的话再把页面跳转过去申请。

不知从何时开始，大家的页面都放在了一个项目里，两个这样的巨石应用融合竟然变成了一件困难的事。

上面这些不合理的现状，都是在不同的场景下，不思考适不适合，单一信奉 “一招吃遍天” 下演化出的问题。

B 端应用，是否应该使用 SPA？ 这其实是一个需要思考的问题。

微前端从某种程度上来讲，是认准 SPA 了必须是互联网下一代应用标准的产物，好像有了 SPA 以后，MPA 就变得一文不值。甭管页面是移动端的还是PC的；甭管页面是面对 C 端的还是 B 端的；甭管一个系统是有 20 个页面还是 200 个页面，一律行这套逻辑。

SPA 不是万能银弹，React 不是万能银弹，Tailwind 不是万能银弹。在新技术出现的时候，保持热情也要保持克制。

ps. 我也十分痛恨 React 带来的这种垄断式的生态，一个 React 组件将 HTML 和 Style 都吃进去，让你即使在做一个移动端的纯展示页面时，也需要背上这些称重的负担。

质疑 “墨守成规”，打开视野，深度把玩，理性消费。

分而治之

分治法，一个很基本的工程思维。

在我看来在一个正常商业迭代项目中的主要维护者，最好不要超过 3 个人，注意是主要维护者(Maintainer) 。

你应该让每个项目都有清晰的责任人，而不是某行代码，某个模块。责任人的理解是有归属感，有边界感的那种，不是口头意义上的责任人。(一些公司喜欢搞这种虚头巴脑的事情，什么连坐…)

我想大部分想引入微前端的需求都是类似如何更好的划分项目边界，同时保留更好的团队协同。

比如导航菜单应该是独立收口独立管理的，并且当其更新时，应该同时应用于所有页面中。类似的还有环境变量、时区、主题、监控及埋点。微前端将这些归纳在主应用中。

而具体的页面内容，则由对应的业务进行开发子应用，最后想办法将路由关系注册进主应用即可。

当然这样纯前端的应用切换，还会出现不同应用之间的全局变量差异、样式污染等问题，需要提供完善的沙箱容器、隔离环境、应用之间通信等一系列问题，这里不展开。

当微前端做到这一部分的时候，我不禁在想，这好像是在用 JavaScript 实现一个浏览器的运行容器。这种本应该浏览器本身该做的事情，难道 JS 可以做的更好？

只是做到更好的项目拆分，组织协同的话，引入后端服务，由后端管控路由表和页面规则，将页面直接做成 MPA，这个方案或许并不比引入微前端成本高多少。

体验差异

从 SPA 再回 MPA，说了半天不又回去了么。

所以不防想想：在 B端业务中使用 SPA 的优势在哪里？

流畅的用户体验：

这个话题其实涵盖范围很广，对于 SPA 能带来的 “流畅体验”，对于大多数情况下是指： 导航菜单不变，内容变化发生变化，页面切换中间不出现白屏。

但要做到这个点，其实对于 MPA 其实并没有那么困难，你只需要保证你的 FCP 在 500ms 以内就行。

以上的页面切换全部都是 MPA 的多页面切换，我们只是简单做了导航菜单的拆分和 SWR，并没有什么特殊的 preload、prefetch 处理，就得到了这样的效果。

因为浏览器本身在页面切换时会在 unload 之前先 hold 当前页面的视图不变，发起一下一个 document 的请求，当页面的视图渲染做到足够快和界面结构稳定就可以得到这样的效果。

这项浏览器的优化手段我找了很久，想找一篇关于它的博文介绍，但确实没找到相关内容，所以 500ms 也是我的一个大致测算，如果你知道相关的内容，可以在评论区补充，不胜感激。

所以从这个角度来看，浏览器本身就在尽最大的努力做这些优化，并且他们的优化会更底层、更有效的。

离线访问 (PWA)

SPA 确实会有更好的 PWA 组织能力，一个完整的 SPA 应用甚至可以只针对编译层做改动就可以支持 PWA 能力。

但如果看微前端下的 SPA 应用，需要支持 PWA 那就同样需要分析各子应用之间的元数据，定制 Service Worker。这种组织关系和定制 SW，对于元数据对于数据是来自前端还是后端，并不在意。

也就是说微前端模式下的 PWA，同样的投入成本，把页面都管理在后端服务中的 MPA 应用也是可以做到相同效果的。

项目协同、代码复用

有人说 SPA 项目下，项目中的组件、代码片段是可以相互之间复用的，在 MPA 下就相对麻烦。

这其实涉及到项目划分的领域，还是要看具体的需求也业务复杂度来定。如果说整个系统就是二三十个页面，这做成 SPA 使用前端接管路由高效简单，无可厚非。

但如果你本身在面对的是一个服务于复杂业务的 B 端系统，比如类似阿里云、教务系统、ERP 系统或者一些大型内部系统，这种往往需要多团队合作开发。这种时候就需要跟完善的项目划分、组织协同和系统整合的方案。

这个时候 SPA 所体现出的优势在这样的诉求下就会相对较弱，在同等投入的情况下 MPA 的方案反而会有更少的执行成本。

也不是所有项目一开始就会想的那么清楚，或许一开始的时候就是个简单的 SPA 项目，但是随着项目的不断迭代，才变成了一个个复杂的巨石应用，现在如果再拆出来也会有许多迁移成本。引入微前端，则可以…

这大概是许多微前端项目启动的背景介绍，我想说的是： 对于屎山，我从来不信奉“四两拨千斤”。

如果没有想好当下的核心问题，就引入新的“银弹”解决问题，只会是屎山雕花。

项目协同，抽象和复用这些本身不是微前端该解决的问题，这是综合因素影响下的历史背景问题。也是需要一个个资深工程师来把控和解决的核心问题，就是需要面对不同的场景给出不同的治理方案。

这个道理跟防沙治沙一样，哪有那么多一蹴而就、立竿见影的好事。

模块加载

模块加载这件事情，从玉伯大佬的成名作 sea.js 开始就是一个非常值得探讨的问题。在当时 jQuery 的时代里，这是一个绝对超前的项目，我也在实际业务中体会过在无编译的环境下 sea.js 的便捷。

实际上，不论是微前端、低代码、会场搭建等热门话题离不开这项技术基础。

import * from * 我们每天都在用，但最终的产物往往是一个自运行的 JS Bundle，这来自于 Webpack、Vite 等编译技术的发展。让我们可以更好的组织项目结构，以构建更复杂的前端应用。

模块的概念用久了，就会自然而然的在遇到浏览器环境中，遇到动态模块加载的需求时，想到这种类似模块加载的能力。

比如在遇到会场千奇百怪的个性化营销需求时，能否将模块的 Props 开放出来，给到非技术人员，以更加灵活的方式让他们去做自由组合。

比如在低代码平台中，让开发者自定义扩展组件，动态的将开发好的组件注册进低代码平台中，以支持更加个性的需求。

在万物皆组件的思想影响下，把一整个完整页面都看做一个组件也不是不可以。于是在一些团队中，甚至提倡所有页面都可以搭建、搭建不了的就做一个大的页面组件。这样及可以减少维护运行时的成本，又可以统一管控和优化，岂不美哉。

当这样大一统的“天才方案”逐渐发展成为标准后，也一定会出现一些特殊场景无法使用，但没关系，这些天才设计者肯定会提供一种更加天才的扩展方案出来。比如插件，比如扩展，比如 IF ELSE。再后来，就会有性能优化了，而优化的追赶对象就是用原来那种简单直出的方案。

有没有发现，这好像是在轮回式的做着自己出的数学题，一道接一道，仿佛将 1 + 1的结论重新演化了一遍。

题外话，我曾经自己实现过一套通过 JSON Schema 描述 React 结构的 “库” ，用于一个低代码核心层的渲染。在我的实现过程中，我越发觉得我在做一件把 JSX 翻译成 JS 的事情，但 JSX 或者 HTML 本身不就是一种 DSL 么。为什么一定要把它翻译成 JSON 来传输呢？或者说这样的封装其本身有意义么？这不就是在做 PHP、ASP 直接返回带有数据的 HTML Ajax 一样的事情么。

传统的浏览器运行环境下要实现一个模块加载器，无非是在全局挂载一个注册器，通过 Script 插入一段新的 JS，该 JS 通过特殊的头尾协议，将运行时的代码声明成一个函数，注册进事先挂载好的注册器。

但实际的实现场景往往要比这复杂的多，也有一些问题是这种非原生方式无法攻克的问题。比如全局注册器的命名冲突；同模块不同版本的加载冲突；并发加载下的时序问题；多次模块加载的缓存问题等等等等等…

到最后发现，这些事情好像又是在用 JS 做浏览器该做的事情。然而浏览器果然就做了， <script type="module"></script>，Vite 就主要采用这种模式实现了它 1 年之内让各大知名项目切换到 Vite 的壮举。

“但我们用不了，有兼容性问题。”

哇哦，当我看着大家随意写出的 display: grid 样式定义，不禁再次感叹人们对未知的恐惧。

import.meta 的兼容性是另外一个版本，是需要 iOS12 以上，详情参考： https://caniuse.com/?search=import.meta

试想一下，现在的低代码、会场搭建等等各类场景的模块加载部分，如果都直接采用 ESM 的形式处理，这对于整个前端生态和开发体验来说会有多么大的提升。

模块加载，时至今日，本来就已经不再需要 loader。正如 seajs 中写的：前端模块化开发那点历史

历史不是过去，历史正在上演。随着 W3C 等规范、以及浏览器的飞速发展，前端的模块化开发会逐步成为基础设施。一切终究都会成为历史，未来会更好。

结语

文章的结尾，我想感叹另外一件事，国人为什么一定要有自己的操作系统？为什么一定需要参与到一些规范的制定中？

因为我们的智慧需要有开花的土壤，国内这千千万开发者的抱负需要有地方释放。

如果没有自己掌握核心技术，就是只能在问题出现的时候用另类的方式来解决。最后在一番折腾后，发现更底层的技术只要稍稍一改就可以实现的更好。这就像三体中提到的 “智子” 一样，不断在影响着我们前进的动力和方向。

不论是小程序、微前端还是模块加载。试想一下，如果我们有自己的互联网底蕴，能决定或者影响操作系统和浏览器的底层能力。这些 “怪啖” 要么不会出现，要么就是人类的科技创新。

希望未来技术人不要再去追逐 Write Once, Run Everywhere 的事情…

新midjourney从注册到使用的超细基础入门教程

Wed, 26 Jul 2023 07:00:04 CST

前言：这篇文章介绍了关于midjourney从注册到使用的超细基础教程，包括注册账号、服务器准备、基础操作、以文生图、以图生图、融合图、抄作业和总结等内容。文章针对的是零基础小白，讲解了如何使用midjourney进行Ai绘图，并介绍了基本操作区域和命令。同时，文章强调了所有操作必须开科技。

*此次教程针对的是零基础小白，大佬可以忽略，后续还会出一些进阶的。

一、注册账号二、服务器准备三、基础操作四、以文生图五、以图生图六、融合图七、抄作业八、总结 *注意：所有操作必须开科技上网哦~ 一、注册账号 1、首先进入midjourney官网: https://www.midjourney.com/ 2、注册discord账号 ①*注意出生日期一定要设置早于2005年（即大于18岁），不然会不让用。 ②验证邮箱。在邮箱里找到验证登录链接验证一下即可（邮箱里如果打不开，就在浏览器打开验证链接，记得开科技）。 3、完成登录，进入主页

ok，完成以上步骤就已经成功注册好了，已经成功一半了，接下来教大家如何使用midjourney

二、服务器准备 Discord支持网页版、客户端、App多端使用，可以根据自己情况进入，我建议下个客户端比较方便。 网页版： https://discord.com/app 客户端下载： https://discord.com/download 1、将midjourney服务器添加到discrod midjourney跟discord之间类似于小程序跟微信的关系找到midjourney服务器，点击添加即可。没有的话可以直接搜索上面如果有提示的话，就正常点击加入，然后验证一下即可 2、建立自己的服务器 可以看到左边已经把midjourney添加成功，但是如果直接在里面生图有时候会被刷掉，所以下面我们来建立一个自己的单独服务器。 ①同样点击点击加号根据步骤操作 ②建立成功后可以看到左边自己服务器的头像 ③将midjourney bot添加到自己的服务器，相当于建了个只有你和他的群聊点击logo先回到midjourney的服务，在任意群组里面找到带有logo的【midjourney Bot】机器人头像单击。（这里可能需要翻一翻，还是比较好找的） ③找到后，单击头像，添加到服务器 ④选择刚刚自己创建的服务器 ⑤授权成功后就可以回到自己服务器开始玩啦

以上就是做完了前期的所有准备工作，下面我们就开始讲如何Ai出图了，准备好了木有！！！

三、基础操作 想要玩好midjourney，首先要了解他的基本操作方法。先简单介绍一下基本操作区域和命令。 1、基本命令 【/imagine】可以通过以下步骤来调取，熟练后可以直接在输入框打“/imagine” 我们来给一个最最基础的案例： ①生成一只猪的图片，在调用的命令框内直接输入：【a pig】 ②完成输入后回车即可开始生成，【waiting to start】代表正在生成，耐心等待即可 ③可以看到已经生成成功了 2、基础操作 ①U/V，命令 第一次出图是四张，分别对应图1234 → U 代表生成大图，点击U1就是将第一张图加细节后，然后生成单张大图 → V 代表参考重构，点击V1就是以第一张图的风格、样式、构图，再生成四张类似的图 ②二级变化 在点击U1/2/3/4后会生成大图，而大图还可以再通过下面命令继续优化 → Make Variations 重做变化，跟V一样用法 → Light Upscale Redo 加轻微细节，中尺寸 → Beta Upscale Redo 加超多细节，大尺寸以上就是基础变化操作，大家可以根据自己需要调整。还有个小经验，就是如果你第一次生成的大图已经很精细了，就不用再继续用Upscale加细节了，因为有时候像是把一张模糊的图直接锐化的感觉，效果不是很好，希望后续midjourney能优化一下。

四、以文生图

官方文档：https://docs.midjourney.com/docs/quick-start 官方文档里有很详细的介绍，有兴趣的可以自己去啃 ①基本句式 有了之前的基础，现在我们开始正式讲解以文生图。首先要知道输入的基本句式： 【关键词描述】+【官方指令】 →关键词之间用【,】隔开 →官方指令之间用【空格】隔开例子:一只猪，一只狗，质量2，风格化56 a pig,a dog --q 2 --s 56 ②官方指令详解 ③关键词 关键词现在网上有很多共享文档进行了详细的分类和列举，直接拿来用即可。常用几大类：风格、材质、媒介、场景、光照、渲染器、视角、精度网上的共享关键词文档： https://docs.qq.com/sheet/DYmd0QlFneFZ4c1Vz

五、以图生图

以图生图，就是常说的喂图。具体怎么操作请看演示 ①上传参考图点击加号，上传文件或者直接将图片拖入也可上传（回车发送） ②右击复制图片链接 *【客户端】可以直接消息里的图直接右击[复制链接] *【浏览器】需要点开大图右击复制（注意是复制图片链接，不是消息链接） ③依旧是【imagine】命令 ④粘贴图片链接+空格+关键词可以添加多个参考图链接，每个链接直接要加【空格】，在图片链接后面加空格可以继续输入关键词，这样生成的图会以参考图的风格来匹配你描述的关键词。 *通过官方命令【--iw 0.2】可以来定义参考图的影响度，数值越大，出图越像参考图 ⑤等待完成即可 六、融合图 就是通过命令将几张图片融合到一起 ①同样的方法找到或直接输入命令回车：【/blend】 ②添加图片（点击增加4那个位置可以继续添加） ③添加完成直接回车即可融合 *多次测试后，发现融合这种艺术类场景效果会比较好，各位可以多尝试

七、抄作业

1、打开midjourney社区排行榜 回到之前的midjourney个人主页： https://www.midjourney.com/app/ 社区排行榜里的作品都带关键词的，可以这里面找到你喜欢的作品然后将关键词复制过来运用到自己的作品中，而且可以通过他们的关键词来学习如何组织自己的关键词 2、复制完整的关键词 氪金玩家是可以打开看详情的，普通玩家就只能看这个小图了，而且当遇到关键词很多无法看全时，有一个小技巧能看到所有的关键词。首先找到你想抄作业的美图，鼠标悬停↓↓↓

八、总结

1、免费次数 普通用户每个用户只有25次免费生成次数，（点一次U/V加细节都算一次，不过他这个25次也不是绝对的，好像是按时间来算，可以超出十来张） 2、结果差异 同样的关键词生成的结果有可能也不一样的 3、思维很重要 其实如果不是闲来无事做实验，大家并不需要去掌握很多关键词，熟练掌握运用基本句式和命令才是关键。通过我提供的或网上现有的关键词库，当做字典一样，在需要时针对性的再去找对应关键词即可。不然到头来收集了一大堆关键词，并没有什么大用。 4、对于Ai的一些拙见 相信很多人会跟我一样的感受，Ai能力如此之强，我们的出路何在？我们苦学基础能力岂不是浪费时间？是的，最初我真的有这个感受，感觉一片迷茫，但冷静分析后还是有些不一样的，分享一下我的见解： ①对于问答类的Ai。许多人认为知识储备不再重要，有他们就足够了。但就现状来看，毫不夸张的说：很多人连最基本的提问能力都没有！是的，即使没有chatgpt之前，在互联网搜索如此发达的今天。只要想，只要主动，几乎是没有搜索引擎找不到的答案。但事实是很多人仍不停的游走在各个水群里问各种基础的问题，我并不讽刺喜欢主动问问题的同学，但对于一些简单的诸如软件快捷键的这种基础问题，不如试试主动百度解决，高效且精准。而另一种情况可能就是，提问者不知道怎么去提问，表达不清楚问题自然找不到对应的答案。是的，Ai固然强大，但说到底，他需要你来正确的“问题”，他才能给你精准的“答案”。除非是后面ai发展到能直接读懂你脑子里的想法，那就无敌了。无论是Ai问答，Ai绘画，还是Ai什么东西，你首先得表达给Ai，才能得出结果来，这是最基本的。 ②对于Ai绘画。不再是把过多的精力投入在繁杂的基础工作上，而是将能力重心放在结果的优化上。例如Ai生成的一张插画，我们要有最起码的高审美能力来判读其是否具有美感；拥有高水准的设计专业知识，来判断图中的细节处理是否到位（诸如：光影、构图、视角、配色等等）；再者就是更加熟练的基础软件实操能力，找出问题后我们要有足够的实操能力通过现有软件来对其优化以达到最终的视觉效果。说到这里，大家还会觉得学习基础能力没有用吗？Ai时代，人人皆扮演老师的角色，我们即是批改学生作业之人！基础知识给我基础的判断能力，基础能力给我们基础的优化能力。只有硬实力才能适应各种时代变迁！无论后面怎么发展，大家还是踏踏实实的学习吧！总结：Ai时代，我们应该对几种能力着重培养： ①更强更准确的表达能力 ②更高更优秀的审美能力 ③更强更主动的学习能力第一次写教程，也是希望能帮到一部分还在门外徘徊的友友们。这次是基础教程，过两天我会再补充一些进阶的，稍微期待一下吧~ 下面是一些我整理的常用且容易出效果的关键词分享：本文针对零基础小白，详细讲解了如何使用midjourney注册和进行Ai绘图的入门教程，并提供了基本操作命令。同时强调了所有操作必须开科技，如有问题，可以关注设计达人一起交流哦。作者：为宇绸缪(xiaozhao.zcool.com.cn) 来源：站酷

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

华为流程体系：IPD流程框架

Fri, 16 Jun 2023 14:39:25 CST

本篇文章作者介绍 IPD 体系主体框架所涉及的一些相关内容，并详细介绍了其三个核心思想：市场管理、流程重组、产品重组。IPD是灵活发展的，熟悉掌握IPD这一思维框架，能对我们日常生活有很多帮助。

今天主要来谈谈 IPD 体系的主体框架所涉及的一些相关内容。

其实关于 IPD 体系，我在之前的文章中都有过不同程度的讲解。

但是，由于这个体系所涉及的面是非常广泛的，这个时候就必须通过一系列的延伸内容从不同的维度来分析和讲解。

只有通过这种方式，才能够让大家最终在工作或者生活中去应用、去思考。即便是你在日常生活中想到了 IPD 这个结构化的思维框架，这也是很有价值的一件事情。

IPD 的全称是指集成产品开发。IPD 的核心思想最早是来源于美国 PRTM 公司的 PACE 理论。

如果大家对 PACE 感兴趣的话，可以看一下《培思的力量》这本书。这套理论详细描述了业界最佳的产品开发模式所包含的各个方面。

后来经过 IBM，以及华为这些企业的实践。IPD 已经成为一套包含企业产品开发的思想、模式、工具的系统性工程。

如果从客户需求到客户满意这个维度出发，也就是从“以客户为中心”的角度出发。

可以将企业的业务划分为三个主要的业务流程。也就是下面这张图所展示的：

第一个是集成产品开发：IPD 流程。这个流程解决的是如何满足需求的问题。
第二个是从线索到回款：LTC 流程。这个流程解决的是如何回款的问题，也就是如何实现企业的商业变现的问题。
第三个是从问题到解决：ITR 流程。这个流程解决的是客服服务的问题。

尤其是对于这个高度行业内卷的时代，你比别人的服务多做一点，客户就可能更愿意选择你。

其中，IPD 流程中融合了大量的优秀的业界实践，主要就涉及：

并行工程。
瀑布式开发流程。
跨职能团队。
产品及周期优化法 PACE。
门径管理流程等。

大家可以看下面这张图。

讲 IPD 体系，就一定绕不开 IPD 的核心思想。

IPD 的流程本身会随着时代、新方法的创新，在动态变化着。

这个时候，核心思想便是 IPD 体系的“根”，起到指导和稳定剂的作用。

IPD 的核心思想包括三个板块，分别是：

市场管理。
流程重组。
产品重组。

大家可以看下面这张图：

下面简单拆分一下。

第一个核心思想：研发是投资行为。

业务经营有两条主线：

一个是实现公司的商业目标；
另一个是满足客户需求。

第一个是为了企业的可持续发展，第二个是企业存在的基础。两者缺一不可。

因此，要把所有研发项目作为投资对象进行组合管理。包括产品开发、平台和技术开发，以及研究类项目。

从一开始就要考虑产品、服务、解决方案和技术的投资回报率。

第二个核心思想是基于市场，也就是需求的开发。

满足客户需求是企业生存的基础。

无论公司战略、市场规划、产品技术规划、各功能部门的规划，还是产品和技术的研发。

甚至是公司其他运营活动，都必须围绕客户需求进行展开。

第三个核心思想是跨部门的协作。

创新和研发是全公司的行为，接力棒式的产品开发流程是很难保证产品质量的。

在 IPD 体系中，无论是需求管理、产品和技术规划、项目任务书开发、产品和技术研发、产品上市，还是上市后的生命周期管理。

都会广泛采用跨部门团队，这样就可以汇集各个领域的专业智慧。

然后形成合力，共同满足客户需求，为产品的商业成功负责。

第四个核心思想是平台化的开发。

为了提高产品、服务、解决方案的开发效率，就需要通过需求管理、产品和技术规划提前识别公共技术和关键技术。

然后单独立项开发，这样才能在产品开发过程中调取这些资源。从而在快速响应客户需求、提高质量、降低成本上同时取得领先优势。

第五个核心思想是结构化的流程。

IPD 体系中的各种流程被划分为若干个阶段。

而且在每个阶段都设置了评审点，按角色归集流程中的活动，便于与组织结构相互匹配。

第六个核心思想是持续改进：灵活发展，与时俱进。

IPD 是灵活发展的，必须在不断吸取业界最佳实践和解决业务问题的过程中与时俱进。

持续变革和优化，以便适应 VUCA 时代的 IPD 体系。

专栏作家

卫朋，公众号：产品人卫朋，人人都是产品经理专栏作家。关注智能硬件领域，擅长市场分析、产品设计开发、生产管理等，喜欢阅读和爬山。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

如何写一篇挑不出毛病的需求文档？

Mon, 13 Mar 2023 18:16:17 CST

作为产品经理，撰写需求文档是一门必须掌握的基本功，那么除了知道需求文档应当包含哪些内容，你知道需求文档究竟应该怎么“写”吗？怎样才能写出一份可以让每个项目成员都能清晰明了得到所需信息的PRD文档呢？一起来看看作者的经验分享。

前言

需求文档是产品经理的基本功，也是产品能力的体现，产品能力行不行看文档就能看出来。

我从实际工作+日常总结，整理了一些自己写PRD的方法，分享给各位，希望能对各位有用~

一、原则与前提

在文章开始前，我们简单看下在什么时候用、谁去用，来明确需求文档的书写原则：

产品需求评审的时候看；
研发技术方案设计、敲代码的时候看；
UI进行界面设计的时候看；
测试写测试用例、执行用例的时候看。

PRD 文档的目的就是让每个项目成员知道需求为什么做、要做什么、怎么做。

所以可以得到PRD的书写原则有：

有理有据：从项目成员知道为什么做；
全面、清晰、准确：让大家知道做什么、怎么做；
易读性：让大家方便快捷的理解文档内容。

明确了原则，还有 2个前提：「需求类型、需求大小」

需求类型有：功能需求、接口需求、性能需求、策略需求、埋点需求、统计需求等等。
需求大小：可以是从0-1的大项目，包含上边的所有需求类型，还有就是日常迭代版本的小需求。

我们接下来文章内容都是基于以上原则与前提，接下来正文开始~

二、需求文档用啥写

我们以终为始，先看需求文档的呈现方式。目前主要有以下2类：

1. Axure一体化需求文档

使用Axure将全部需求文档，最终通过Axure打包提供出去。好处是方便查看，看原型的基础上又能看文档说明。但有一种不是很“严肃”的感觉。

2. Word版

通过Word进行需求描述，并统一提供。容易留存，也比较正规，在阅读上以文字为主。

具体选择那种方式，可以先看公司要求。

像我之前有公司要求，必须用word，就算是有大量原型的，也只能把页面原型画好，然后再复制到word里，在word写需求内容。

如果没有要求，具体采用的方式可以看不同的需求类型：

如果只涉及到画原型的，可以使用Axure。

如果只有偏后端需求的，逻辑相关的需求，比如说是接口需求、算法需求，并不涉及到前端需求的，我们可以直接使用word写。

如果是做的大项目，同时有功能需求，又有接口需求、算法需求的，我建议都放在一起，比如说都用Axure写需求。

我之前做新项目的时候，同时提供了功能需求的axure文档+word版的接口需求，后来用例评审的时候，测试说不知道word版接口需求，之后我就统一写在axure里了。

三、需求文档包含哪些内容

需求有大有小，同样的需求文档也有大有小，小到直接一句话描述，大到上百个原型页面，好几万个字。

一句话的需求我们在这就不说了，我们说下正常的需求文档。

不论是使用Axure还是word，也不论需求大小是什么， PRD文档中一般需要包含以下内容：

1. 文档修改记录

需求文档在需求评审、研发、测试过程中一定会改的。

比如说加个限制，补充个遗漏的逻辑等等，不过我们一定要记录下修改内容，并及时更新需求文档、及时同步项目成员。

一般通过表格展示出以下内容：

修改内容：说清楚修改的哪个模块，哪个页面、哪个功能点。当然也可以分成修改模块、修改页面多个列。
修改原因：就是为啥要修改，比如说逻辑缺失需要补充等等。
修改人：谁改的。
修改日期：修改时间。

在使用Axure时，我们可以在文档修改记录中加上文本链接跳转，项目成员点击文字可直接进入到对应页面查看。

对于word，也是同样的，加个文档修改记录。

对于文档修改记录，不仅在PRD文档中可以用到，在写其它文档时都可以加上，比如操作手册。

2. 项目背景 or 需求背景

背景同样也是有大有小，对于新项目，则需要介绍下整个项目的大背景。对于每个需求，我们同样也可以简单说下需求背景。

参考格式如下：

当前的现状是什么，有哪些问题/痛点，这些问题导致了什么结果，为了解决这个问题，我们需要采取什么动作，达到什么目的，能够获取哪些收益，产生什么价值。

3. 名词解释

如果有专业名词，一定要写上。

在不同行业、不同公司、不同团队中都有专门的名词，项目成员是不明白一些名词的，这个时候一定要说明。

比如说抗菌药物DDD值，绝对的专业名词，不说一般没人知道。

另外在说名词解释的时候，尽量加上示例说明方便大家快速理解。

4. 流程图

当涉及跨角色、跨系统、跨模块、多判断逻辑时，我们一定要画出来，让各方更快地了解产品流程。

流程图同样有大有小：

包括整体产品业务流程图、单个模块的流程图、单个功能的流程图。

1）整体流程图

为了将这个产品的功能业务串起来，可以不用画的太详细，画出大的概览图，从大而全的角度将这个项目表达出来。

一般是在0-1的新项目中画，日常迭代的需求中不需要。

2）单个模块功能的流程图

当一个功能模块功能很多时，为了将模块内的功能串起来，说清楚单独模块的流程，这个就要画的细致一点。

当涉及到新的模块时一定要画。

3）单个功能的流程图

对于复杂的单个功能，涉及到的处理逻辑比较多时，我们也需要画出单独的流程图进行说明。

流程图的类型有很多种，像业务流程图、页面流程图、泳道图、uml里的时序图、用例图等等。

我们可以基于不同流程图的特性去选择不同的类型，比如有多角色时，我们可以使用泳道图。

对于UML，像用例图、序列图，在画的时候有一定的门槛，同样的一定会有团队成员看不懂。我是从来没画过，所以大家可以自行选择学习与绘制。

对于页面流程图，是表达出页面之间的跳转逻辑，像移动端的页面，我们可以直接平铺出每个页面，展示出页面间的跳转逻辑。

对于PC端产品，页面尺寸较大，我们可以通过页面名称展示出页面流程。

流程图的能够达到业务清楚，表明重点，项目成员能够快速理解的目的就行。

5. 需求说明

对需求的详细说明，这一点肯定是必须的，我们下边单独说。

以上内容是我认为在写需求文档时，需要包含的内容，下边的内容我们则可以自行选择~

1）产品架构图

在0-1产品搭建的时候进行展示，将整个产品抽象化，通过数据层、服务层、应用层、展现层等抽象层面表现出产品的整体架构。

来自Processon

产品架构图是非常大的层面，当你没有独立负责一条业务线的时候，很难有这种大的架构概念。

当你需要规划一条产品线的时候，可以画出来产品架构图，让之后的产品方向再这个大的框架下去走。

我也是在最近这2年，独立负责产品线的时候才开始绘制的，主要是和领导们汇报使用的。

具体怎么画，大家可以在平台上搜一下，有很多。

2）功能架构图 or 信息架构图

对于功能架构图，就是写清楚产品功能的层级架构，简单说就是一级菜单、二级菜单是什么，每个菜单里有哪些功能，展示出功能的层级关系。

我一次都没有画过。

对于功能架构的展示，我一般在画原型的时候规划出来，然后直接画原型。

当然也可以通过思维导图的方式画出来，但是吧，画出来也没人看。

还有一个信息架构图，这个我也没画过。

我有很长的一段时候都没整明白功能架构图与信息架构图有啥区别~

现在我的理解是：

功能架构图是展示出功能层级关系，体现出菜单-功能的层级逻辑。
信息架构图是展示出每个功能页面内的展示字段内容，主要用于研发设计表结构与表字段。

对于功能架构图和信息架构图，一般是在产品0-1的时候画，而且涉及到的内容比较多，多的内容一定没人去看。

到底要不要画是一方面，大家一定要知道功能结构图和信息架构图是个什么东西，具体画不画大家自行选择。

四、画原型写文档

需求类型里有一个功能需求，这个就是每个产品避免不了的，所以我们单独说下画原型+写文档~

1. 首先根据要做的需求范围进行分类

当有多个需求类型时，按类型进行分类，使用Axure时可以通过建立文件夹。

使用word则可以加个一级标题。

目的是将需求有层级的依次展示出来。

然后在不同的文件夹下，在进行分级。

比如「功能需求说明」文件夹下有多个功能模块，则按照模块/菜单名称建立子文件夹，然后再在每个模块下建立对应页面；

当同一个页面内有多个tab页/子页面时：

对于PC端，我一般是分页面说明；APP的页面尺寸小，我们可以在一个Axure页面内统一说明。

然后再对每个页面单独画原型，写文档。

2. 需求文档的表现方式

当采用Axure写需求文档的时候，常见的布局是：左图右文。

左边展示原型图，右边展示需求说明。

对于word版，常为：原型页面展示，单独写文档说明。

3. 提取公共逻辑，放入全局说明

在画原型、写文档的时候，一定会有相同的功能逻辑、相同的需求逻辑。

例如说后台系统，会有一堆的列表，列表就涉及到分页数量、默认排序等。

我们可以直接统一使用全局说明。

将相同的功能逻辑、需求内容当在一个单独的全局说明里，在全局说明里进行单独说明。

当在某个页面中需要说明的功能点已经在「全局说明」里存在时，可以加个说明：请见全局说明。

同时对文字添加文字跳转链接，阅读者点击可直接跳转到对应的全局说明页面。

3. 功能点序号标注

先画出原型图，在原型中标注「序号」，然后在右侧按照相同的序号进行功能需求描述。

标注顺序：一般按照从左到右，从上到下的顺序。
标注哪些点：需要进行功能说明的功能点， 但是并不意味着每一个点都要进行标注。

我一般按照 从大到小，按照模块化的方式。

以下方的表单页面为例：

当原型画出后，在页面上标个序号[1]，对页面进行下简介，一般说明页面是什么，使用角色是谁。

然后继续标注「返回」，对「返回」进行说明。

因为点击返回时，没有添加其它判断逻辑（如是否二次确认），所以直接描述交互逻辑即可。

然后接着对下方的「患者信息」进行标注。

我们可以看到「患者信息」里有很多字段，我不建议对每个字段进行说明。

我们直接对「患者信息」整个模块进行标注，然后对每个字段进行说明。

由于只是表单输入，我们需要说明是否必填、采用什么组件、是能输入文字、还是数字输入框，数字范围限制、数字小数点限制（如最多2位小数）、输入小数点超过如何处理（是直接限制输入，还是能四舍五入）、字符长度限制、当字符输入超长如何处理。

如果是采用选择框，选择框里的值是写死的，还是从哪里取值。

……

这就是对需求的描述，我们需要尽可能的写全，就是尽可能的把考虑到的限制加上，你写的越全，在评审的时候，才会少挨怼。之后的需求变更才会少。

（现在看其实上边的需求描述还是不全，比如漏了小数点位数说明，文本输入框内能不能输入表情emoji符号等等）

当页面内出现弹窗时，我们需要对弹窗里的内容进行说明，单独对弹窗里功能点进行标注，然后再下方继续对需求进行说明。

对于弹窗里的内容，我一般从「1」开始重新编号。不把序号顺序和其他页面夹杂在一起。当调整一个功能点后，需要重新编号，增加了多余的工作量。

4. 需求详细书写

对需求的详细描述，是最核心的内容，我们可以按照下方的格式来写：

标题：功能点名称。
角色权限：如当前登录用户角色为管理员时，则显示此按钮。
规则逻辑：主要有 校验逻辑、前置条件、触发时机等，当涉及到的校验逻辑太多时，可以采用 分行分段、添加序号、使用表格等方式，将每个逻辑有条理的全部说明清楚。

比如：确定按钮。

当角色为「管理员」时，展示出确认按钮；

当XX未填写时，按钮显示为禁用状态，点击时出现toast提示：请填写XXX。
当XXX、XXX全部填写后，按钮置为可点击状态，点击后跳转至XXX页面。

极值说明：如输入框输入字符的长度，数字输入的范围值。

交互说明：如点击调整至XXX页面。

在写需求时，根据不同的需求内容，尽可能的将全部内容写清楚。

这个时候一定会有一个问题：写不全。

我们可以明确一点，没有产品经理把所有情况都考虑到，乔布斯、张小龙也考虑不了那么全。

我们需要做的是尽可能的考虑全，尽可能是个很虚的词，受行业经验、项目经验等影响，不同级别的产品经理的需求文档写的水平很显而易见，当然你考虑的越全面，产品能力可以说就越强。

我们可以在需求评审前，先和研发提前碰下，避免有大的遗漏。

也可以借助「需求自查表」来辅助，自查出遗漏的说明。

5. 其它

1）文字描述言简意赅， 避免口语化，别使用模棱两可的文字。需求文档里的内容必须明确，别写「尽量」「尽快」。

2）添加示例：被误解是表达者的宿命，文字说明都会有一定的片面理解，对于比较复杂的内容，我们可以添加示例说明：

同时在原型上，尽量使用贴合实际场景的内容。比如说时间别写出：13:88:99。

3）为了便于阅读，可以 采用多分段，多分行，加序号的方式。

4）使用标点符号，将内容说清楚，如：点击「确认」按钮，跳转至【XXX页面】。

关于标点符号，大家可以看这个文章：https://zhuanlan.zhihu.com/p/359255980

5）结合axure的特性，添加文字链接，便于阅读者快速跳转查看，不用自己找。

添加「返回」按钮，比如阅读者跳转到【全局说明页面】，看完后，想在回到来源页继续看需求，我们可以在【全局说明页面】中添加个「返回来源页」按钮，加个返回上一页的交互，直接能返回。

6）对于变量值，使用特殊符号标记下

对于会变化的值，我一般使用用两个百分号，如下方的‘科室名称’，会根据不同的选择展示不同的名称，所以我就通过‘%科室名称%’进行表示，然后单独说明，并举例说明。

7）重要内容进行标记

可以通过加粗、换个颜色等方式进行提醒，当内容较多的时候，大家很容易忽略掉，所以很有必要进行加粗加大标色提醒。

8）涉及到逻辑时，可以使用公式进行说明

如：当A+B≥100时，则XXXX。

9）写完后自己再过一遍

就像上学做题后，自己zai再验算一遍，在写文档的时候，自己肯定会有抽风的时候，不知道哪个地方就给写错了。

10、对外提供时，对于Axure，可以打包出html提供。

如果是word版本，可以提供出pdf版。

以上是对功能需求的说明，对于接口需求、性能需求、埋点需求等非功能性需求，当涉及到的时候，一定要写上，不然就是需求遗漏了。

我之前一直以为产品经理只需要写功能需求就够了。

有一次让我写接口需求，我就很郁闷，这明明是技术的活，干嘛产品写。后来，我明白了一件事，产品经理不往前站，之后就会是一堆坑。

除了接口需求，还是像研发数据库建表时，这些我也建议产品经理去介入，因为表里有哪些字段，字段最大长度是多少，需要建哪些字段等等，都是和业务有关系的。

举个示例，药品的「规格」这个字段，研发把最大长度设置成250个字符，但是在实际业务上，「规格」会有2000个字的情况。

研发绝对是不理解的，所以最清楚这个情况的是产品，就需要提醒研发关注下。避免上线后，字数超长导致保存错误。

对于性能需求怎么写，大家可以看这篇：《5000字详解性能需求》。

对于接口需求、埋点需求等大家可以在平台上搜一下，接口需求可以看：https://www.woshipm.com/pmd/2297401.html

总结

写出好的需求文档受很多方面的影响，从前期的需求分析，当确定业务流程，然后再到画原型，最终把PRD写出来，这里边涉及到的内容非常非常多。

这篇文章是给大家提供的概述，大家可以在日常中总结积累，多和项目成员沟通，每一次需求评审就是一次淬炼，挨个一次怼后就总结，下次别再犯。

另外，当你把一篇完美的需求文档交付后，一定会有研发、测试不看的，只会问，就不看文档。我一般是“微笑服务”，把文档内容截个图发过去。

本文由 @王大鹿原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

译文 | A poor man's API

Fri, 02 Dec 2022 10:14:21 CST

作者：Nicolas Fränkel
翻译：Sylvia
https://blog.frankel.ch/poor-man-api/

在 API 日渐流行的年代，越来越多的非技术人员也希望能从 API 的使用中获利，而创建一套成熟的 API 方案需要时间成本和金钱两方面的资源加持。在这个过程中，你需要考虑模型、设计、REST 原则等，而不仅仅是编写一行代码。

如何打造一个具有高性价比且能持续迭代的产品，成为越来越多技术团队的目标。 本文将展示如何在不编写任何代码的情况下，简单实现一个 API 实践。

方案初试

该解决方案主要使用的是 PostgreSQL 数据库，PostgreSQL 是一个开源 SQL 数据库。同时我们没有编写 REST API，而是使用了 PostgREST 组件。

PostgREST 是一个独立的 Web 服务器，它可以将 PostgreSQL 数据库直接转换为 RESTful API。如果你想了解 PostgREST 的使用方法，可以参考入门指南文档，内容非常全面且开箱即用。

接下来，我们将它应用到一个简单的示例中。

具体步骤

以下过程你可以在 GitHub 上找到完整源代码。
下方展示了一个通过 CRUD API 公开的 product 表。

由于我没有找到任何现成的 Docker 镜像，所以我单独创建了一份新的 Dockerfile。其中主要涉及依赖项的安装和参数化数据生成。

Dockerfile

  FROM debian:bookworm-slim                                                   
ARG POSTGREST_VERSION=v10.1.1                                               
ARG POSTGREST_FILE=postgrest-$POSTGREST_VERSION-linux-static-x64.tar.xz     
RUN mkdir postgrest
WORKDIR postgrest
ADD https://github.com/PostgREST/postgrest/releases/download/$POSTGREST_VERSION/$POSTGREST_FILE \
    .                                                                       
RUN apt-get update && \
    apt-get install -y libpq-dev xz-utils && \
    tar xvf $POSTGREST_FILE && \
    rm $POSTGREST_FILE

之后，Docker 镜像在 /postgrest 文件夹中会包含一个名为 postgrest 的可执行文件。这里可以通过 Docker Compose 来部署：

docker-compose.yml

  version: "3"
services:
  postgrest:
    build: ./postgrest                                   
    volumes:
      - ./postgrest/product.conf:/etc/product.conf:ro    
    ports:
      - "3000:3000"
    entrypoint: ["/postgrest/postgrest"]                 
    command: ["/etc/product.conf"]                       
    depends_on:
      - postgres
  postgres:
    image: postgres:15-alpine
    environment:
      POSTGRES_PASSWORD: "root"
    volumes:
      - ./postgres:/docker-entrypoint-initdb.d:ro

接下来可以执行以下命令，查询前文提到的 product 表：

  curl localhost:3000/product

得到如下结果反馈：

  [{"id":1,"name":"Stickers pack","description":"A pack of rad stickers to display on your laptop or wherever you feel like. Show your love for Apache APISIX","price":0.49,"hero":false},
 {"id":2,"name":"Lapel pin","description":"With this \"Powered by Apache APISIX\" lapel pin, support your favorite API Gateway and let everybody know about it.","price":1.49,"hero":false},
 {"id":3,"name":"Tee-Shirt","description":"The classic geek product! At a conference, at home, at work, this tee-shirt will be your best friend.","price":9.99,"hero":true}]

方案优化

尽管上文提到的这套解决方案有效，但仍存在很大的改进空间。比如数据库用户不能更改数据、实际操作中每个人都可以访问相关数据等。这对于与产品相关的数据来说，可能不是一个大问题，但如果是医疗数据呢？

PostgREST 的官网使用文档中提到了这一点，并明确提出：建议用户使用反向代理。

提到反向代理，就不得不将目光转向到 API 网关行列。与 NGINX 不同，这里我选取了 开源领域非常活跃的 API 网关产品 — Apache APISIX。APISIX 是一个动态、实时、高性能的 API 网关，提供了负载均衡、动态上游、灰度发布、精细化路由、限流限速、服务降级、服务熔断、身份认证、可观测性等数百项功能。

首先，我们可以在 Docker Compose 文件中补充 APISIX 相关信息，包括 APISIX 及其依赖的存储 etcd，而 etcd 主要用于存储 APISIX 的路由、插件等配置信息。

docker-compose.yml

  version: "3"
services:
  apisix:
    image: apache/apisix:2.15.0-alpine                              
    volumes:
      - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro
    ports:
      - "9080:9080"
    restart: always
    depends_on:
      - etcd
      - postgrest
  etcd:
    image: bitnami/etcd:3.5.2                                       
    environment:
      ETCD_ENABLE_V2: "true"
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: "http://0.0.0.0:2397"
      ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2397"

然后将 APISIX 配置为 postgrest 的代理进行调用。

  curl http://apisix:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: 123xyz' -X PUT -d ' 
{
  "type": "roundrobin",
  "nodes": {
    "postgrest:3000": 1                                                             
  }
}'
curl http://apisix:9080/apisix/admin/routes/1 -H 'X-API-KEY: 123xyz' -X PUT -d '    
{
  "uri": "/*",
  "upstream_id": 1
}

现在再来查询端点，会得到与上文一致的返回结果。

  curl localhost:9080/product

添砖加瓦

虽然到目前为止，我们还没有添加任何实际项目，但准备工作已经全部就绪了。接下来就让我们为这个 API 添加一些其他功能，让其更安全有效，易于追踪。

DDoS 保护

API 作为一个连接属性的组件，必然要保证其过程中的传输安全。因此，在这里我们对 API 增加一些防护，让其免受 DDoS 攻击。APISIX 提供了非常多的官方插件，涉及鉴权、流量处理、监控等等。为了防止 DDoS，我们可以使用 APISIX 的 limit-count 插件。

在 APISIX 中使用插件时，你可以在创建特定路由时在每个路由上设置某个插件。如果你想让某个插件在每个路由上都生效，则可以使用全局规则。如下方所示，我们希望在默认情况下可以保护每个路由，所以使用全局规则设定 limit-count 插件。

  curl http://apisix:9080/apisix/admin/global_rules/1 -H 'X-API-KEY: 123xyz' -X PUT -d '
{
  "plugins": {
    "limit-count": {                 
      "count": 1,                    
      "time_window": 5,              
      "rejected_code": 429           
    }
  }
}'

现在，如果我们执行太多的请求，APISIX 将会保护上游。

  curl localhost:9080/product

  <html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>

增加鉴权

PostgREST 还在根端提供了一个 OpenAPI endpoint。因此，我们现在有两条路由： / （控制 Open API 规范）和 /product （控制产品）。

假设我们现在需要制定一套限制访问的操作，即不允许未经授权的人访问数据。普通用户可以访问产品端信息，而管理员用户可以访问 Open API 规范和产品端信息。

APISIX 提供了几种身份验证方法，这些身份认证方式都可以通过插件进行实现。这里我们选取 APISIX 中最常用也是最简单的认证插件 key-auth，它依赖于 Consumer（消费者）抽象。 key-auth 插件的使用中需要一个特定的 header，这样插件就可以根据值数据进行反向查找，并找到其对应的 Consumer。

以下代码展示了如何新建一个 Consumer：

  curl http://apisix:9080/apisix/admin/consumers -H 'X-API-KEY: 123xyz' -X PUT -d '    
{
  "username": "admin",                                                               
  "plugins": {
    "key-auth": {
      "key": "admin"                                                                 
    }
  }
}'

同样的，我们需要对 Consumer user 和 Key user 进行相关操作。现在可以创建一个专用路由来配置它们，以便只有来自 admin 的请求才能通过：

  curl http://apisix:9080/apisix/admin/routes -H 'X-API-KEY: 123xyz' -X POST -d ' 
{
  "uri": "/",
  "upstream_id": 1,
  "plugins": {
    "key-auth": {},                                                             
    "consumer-restriction": {                                                   
      "whitelist": [ "admin" ]                                                  
    }
  }
}'

然后使用以下命令测试一下：

  curl localhost:9080

发现并没有起作用。这是因为我们没有通过 API 密钥的 header 进行身份验证。

  {"message":"Missing API key found in request"}

添加 header 后再次进行测试：

  curl -H "apikey: user" localhost:9080

{"message":"The consumer_name is forbidden."}

发现仍然没有效果。这是因为这里 API key 为 user ，我们前边仅为 admin 也就是管理员设置了相关权限。所以如果更换为 admin ，就会如期返回 Open API 规范的相关信息。

配置监控

在软件系统中，总有一个被人们低估重要性的功能 —— 可观测性。在生产环境中部署了任何组件，都需要监控其运行状况。

如今，很多服务都提供了可观测性的功能，比如 Prometheus。得益于 Prometheus 的开源属性，它被广泛应用于实践中。因此，这里我们也选用 Prometheus 进行相关数据的监控。

为了通过图表等形式显示数据，我们也同时需要依赖于 Grafana。接下来，将这些组件添加到 Docker Compose 文件中。

docker-compose.yml

  version: "3"
services:
  prometheus:
    image: prom/prometheus:v2.40.1                                    
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml    
    depends_on:
      - apisix
  grafana:
    image: grafana/grafana:8.5.15                                     
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning              
      - ./grafana/dashboards:/var/lib/grafana/dashboards              
      - ./grafana/config/grafana.ini:/etc/grafana/grafana.ini         
    ports:
      - "3001:3000"
    depends_on:
      - prometheus

以上操作需注意：APISIX 的默认监控方案中自带 Grafana，因此只需从 APISIX 中获取相关配置即可。同时将默认端口从 3000 更改为 3001 是为了避免与 PostgREST 服务发生冲突。

一旦监控基础设施到位，我们只需要指示 APISIX 以 Prometheus 期望的格式提供数据即可。可以通过配置插件和新的全局规则来实现这一目标：

config.yaml

  plugin_attr:
  prometheus:
    export_addr:
      ip: "0.0.0.0"             
      port: 9091

  curl http://apisix:9080/apisix/admin/global_rules/2 -H 'X-API-KEY: 123xyz' -X PUT -d '
{
  "plugins": {
    "prometheus": {}
  }
}'

此时发送几个查询请求，并打开 Grafana 仪表板，可看到类似数据。如果运行较多请求，则会出现更丰富的数据仪表。

总结

创建一个成熟的 RESTful API 是一项巨大的投资。你可以通过 PostgREST 将数据库暴露在 CRUD API 中来快速测试一个简单的 API。但是，这样的体系结构不适用于实际生产。要想使其更具实践性，就需要在 PostgREST 前设置一个 facade、一个反向代理，或者更好的 API 网关。

Apache APISIX 作为云原生 API 网关，提供了广泛的特性，从流量处理到认证授权和可观测性等。有了 APISIX，你就可以用较低的成本快速验证你的 API 需求。锦上添花的是，当你验证需求完成之后，还可以保留现有的 facade，并用自定义开发的 API 来替换 PostgREST。

我们需要怎样的 Service

Mon, 10 Jan 2022 09:57:26 CST

14 世纪，英格兰的逻辑学家奥卡姆在他的《箴言书注》中说「不要浪费过多的东西，去做那些用较少的东西同样可以做好的事情」。后来这句话被简化为「奥卡姆剃刀原理」，即：如无必要，勿增实体。奥卡姆剃刀在各个领域都有他的运用，他不是一个公理，没有严谨的推导过程，但他却是一个在实践中被证明非常有效的解决问题的手段。

在编程世界里，有太多我们习以为常的东西，我相信存在即合理，同时我也相信存在都有前提，而前提会随着时间变化甚至消失。下面我想跟大家探讨下，我们前端项目中那些应该被剃刀剃掉的东西。

前端项目里的 service 层

在一个前端项目中，一般包含以下文件目录：

containers：页面
components：组件
utils：工具方法
routes：路由
services：数据服务
index.js 入口文件

我们的业务代码基本都在 containers components 里，utils 和 routes 也是必不可少的，但仔细思考我们就会发现，这里有个 services 文件夹，他被称为数据服务层，是我们跟后端打交道的。这一层真的需要吗？
我们来看看大家是怎么使用 service 的。

  // services  文件夹下的 accoutService.js

import { post } from '@/utils/request';

// 获取账号列表
export const getAccountsList = params => post('/api/accounts.json', params);
// 新增账号
export const insertAccount = params => post('/api/insertAccount.json', params);
// 更新状态
export const updateAccount = params => post('/api/updateAccount.json', params);
// 校验账号查询
export const checkAccount = params => post('/api/checkAccount.json', params);

-------- 使用 ---------

import { getAccountsList } from '@/services/accountService'

const App = () => {
  const [name, setName] = useState('');
    useEffect(() => {
      getAccountsList().then((res) => {
       setName(res.name);
    });
  }, [])
  return <div>{name}</div>;
};

从上面的代码我们可以看出，services 文件下基本是一些模板代码，偶尔有少见的一些数据转换。这些内容对于我们的业务代码来说，都是非业务相关的，写这些模板性的控制代码真的有必要吗？

service 里包含什么？

数据转换逻辑 converHandler
数据请求工具 request
请求地址定义 url
全局拦截器 interceptor
附加功能 openApi

数据转换逻辑 converHandler：并不通用，有的一个请求在不同的页面需要走不同的转换逻辑，这些转换逻辑一般会写在调用位置的代码里，我也建议这么做，因为数据转换也是这块某个 container 的功能，而且为了方便测试，建议添加 handler.js 将转换逻辑抽离出来。

数据请求工具 request：主要是封装各种请求，这部分需要统一。非业务相关，可以提出来。

请求地址定义 url：这部分是强业务相关的，不应该放到 service 里，而是作为 service 的一个配置，由外部输入。

全局拦截器 interceptor：处理一些通用的业务状态码，比如编辑成功 10001，这部分也是强业务相关的，而且相对比较复杂，但是可以通过配置 schame 来描述，后面再讲。

附加功能 openAPI：如果你系统的接口想让别的系统复用，比如 MTEE 基础平台的接口需要复用给运营平台，那么前端需要提供领域物料，领域物料里会发请求，发请求要解决跨域、登陆、授权的问题，openAPI 应运而生。

综上可以看出，service 层只需要一些统一的逻辑处理和配置文件就能描述清楚，甚至我们可以把 Service 层简化为

$$service = request + config$$

我的 service 包

由此，我希望能设计这样一个 service 包，他需要包含下面的功能：

请求

支持常见的 get post jsonp 请求，以及对于这些请求的附加方法，比如 debounce、throttle、缓存、loading 等功能。也可以提供大家比较喜欢的 hooks API。

接口配置

一个接口包含域名 domain，地址路径 path，请求方法 method，参数 params，一些常见功能的开关，比如开启防抖 { debounce:true } 。参数的配置里，可以添加该参数的基本属性，比如是否必选 { require: true } ，这样包内可以对参数做必要的校验，这样可以保证非法数据传入后台。

环境切换

环境切换是一个非业务相关的功能，他不应该硬编码到代码里，带到线上。他应该只是一个配置，尽量与代码脱离，因此是用浏览器插件来切换，就是一个很好的方法。可以设计 service 包接收一个 domainMap，这个 domainMap 来自 window.GlobalConfig 下的某个变量，浏览器插件可以动态改变这个变量，就可以做到环境的切换了。

网关转发

我们写代码追求复用，从代码块的复用到组件复用，再到业务能力的复用，而业务能力复用的一个载体就是领域物料。一个领域物料里很有多个接口请求，如果我们把原来在业务代码里的组件拆出来作为领域物料的话，就不得不把项目里的 service 层也要打包进去，这样才能发送请求和处理一些统一的异常。上面的我提到的把是service 层做成一个包，别人在使用的时候，只需要传配置进来，也是出于领域物料这个场景。
这之后，我们还要解决一个问题：领域物料在不同站点使用带来的接口跨域问题。我们现在的解决办法是，前端搭建一套基于 node 的网关，用于做接口转发和鉴权。service 包里会集成这个过程，外部使用者只需要配置开不开启网关就可以了。他完全不需要知道网关是如何转发的，就像在自己的站点下写组件一样。

接口文档

我们在接手别的项目的时候，总是不容易找到他的接口文档，因为文档和代码是割裂的，文档的维护也有滞后性，甚至慢慢文档的链接也找不到了。因此，代码和文档应该在一起，最好是代码即文档。大家可能觉得用注释就可以了，但程序员总是要求别人写注释，但自己却不爱写。写注释如果可以像写代码一样，或许能规范这部分的行为。例如：

  {
    name: '获取账号',
    domain: DOMAIN.TAOBAO,
    url: '/api/getAccount.json',
    method: METHOD.GET,
    params: {
      userId: {
        name: '策略包id',
        type: PARAM_TYPE.STRING,
        required: true,
      },
    },
    response: {
        name: '账户名字'
    },
  },

这里用配置文件的方式规范了文档的形式，还可以与浏览器插件相结合，通过插件来查看当前用的接口文档。

异常拦截

异常分为服务器异常和业务异常，服务器异常一般是用 http 状态码，400、500等；业务异常则需要是用 body 里的 code 来表示。在真实的业务实践中，我们发现对于服务器异常我们是很容易写出通用的拦截器做一些处理的，但是对于业务异常，就相对比较复杂了，这里面存在几个问题：

很多后端不习惯使用 code 返回相应的业务编码来表示不同的状态。
前端直接使用后端返回的 message 展示给用户，这里有两个问题，① 后端的需要引入第三方库对 message 做国际化 ② 后端定义的 message 不是用户语言，用户一般是看不懂的。因此这里就需要一个第三方系统的参与，他提供业务 code 和前端动作的映射关系表，比如：后端返回 code:10000，前端应该弹窗并展示 message，定义的 json 如下：

  {
  code: 10000,
  message: '编辑失败',
  debug: '后端数据库读写异常，堆栈信息：',
  showType: 'openDialog'
}

这里的 message 是可以根据不同语言环境返回不同语言文字的，showType 表示了前端的动作类型，这个是可枚举的，其中肯定有一种动作是，不做动作，直接透传。这个第三方系统，就可以配置不同编码的动作，有利于精细化的管理异常，给用户更好的体验。

落地

实践是检验真理的唯一标准，基于上面的理想，我的 service 包也已经成型，使用他非常简单。只需要两步：
① 配置文件
② 引入包
③ 业务代码里调用

配置

  // 配置文件 account.js

import { METHOD, PARAM_TYPE } from '@ali/hulu-service';

export const DOMAIN = {
   TAOBAO: '//taobao.com',
   ALIPAY: '//alipay.com',
};

export default {
  getAccount: {
    name: '获取账号',
    domain: DOMAIN.TAOBAO,
    url: '/api/getAccount.json',
    method: METHOD.GET,
    params: {
      userId: {
        name: '策略包id',
        type: PARAM_TYPE.STRING,
        required: true,
      },
    },
    response: {
        name: '账户名字'
    },
  },
};

引入包

  import HService from '@ali/hulu-service';
import account from './account';

// 初始化service
const service = HService.init({
  urls: [
      account,
  ]
});

export default service;

调用 API

  import Service from './service';

const App = () => {
  const [name, setName] = useState('');
    useEffect(() => {
      Service.getAccount().then((res) => {
       setName(res.name);
    });
  }, []);
  return <div>{name}</div>;
};

export default App;

同时基于浏览器插件，可以快速的切换环境，查看接口文档等。

想想边界

开头，我们说到奥卡姆剃刀，如无必要，勿增实体，这个的前提是，有清晰独立的实体，如果我们的实体之间相互勾连耦合，那又如何剃掉不必要的实体呢。
其实，无论做任何软件构架，都要分清楚边界，也就是一个模块他的定位是什么，哪些功能是他该做的，哪些不是。这里面一个非常重要的依据就是是否易于变更。哪些是业务的、常变化的，哪些是非业务的、一般不变的。我们的代码常常，坏就坏在边界不清晰，或者是边界原则没有一以贯之。工程代码里耦合了业务，业务代码里掺杂着工程（比如环境判断）。代码的坏味道是一点一点积累而成的，而这个坏的开始，就是初始的架构设计边界不清晰，没有用代码定义规范。
抵抗代码的腐败，这是一个漫漫长路，没有银弹，但确实可以精进一个人的系统思维。

作者：ES2049 / 黑石

文章可随意转载，但请保留此原文链接。
非常欢迎有激情的你加入 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com 。

网络数字身份认证术

Sun, 02 Jan 2022 16:38:13 CST

这篇文章是《 HTTP API 认证授权术》的姊妹篇，在那篇文章中，主要介绍了 HTTP API 认证和授权技术中用到的 HTTP Basic, Digest Access, HMAC, OAuth, JWT 等各种方式，主要是 API 上用到的一些技术，这篇文章主要想说的是另一个话题——身份认证。也就是说，怎么确认这个数据就是这个人发出来的？

用户密码

要解决这个问题，我们先来看一个最简单的解——使用密码，通常来说，在网络上要证明一个人的身份的话，都需要这个人的一些私密而唯一的东西。比如，像密码这样的东西，很多地方，只要你提供了你的用户名+密码，就可以确定这个人是你（注明：关于密码管理，强密码设定，密码泄漏，密码破解以及密码哄骗不在这篇文章的话题中），也就是说，这个密码是非常私密的事，我们可以假设，这个事全世界只能有当事人一个人知道，所以，当当事人得供正确的密码，我们就可以认证这个人了。

为了加强密码的安全程度，一般会使用 2FA（Two-factor authentication）或 MFA（Multi-factor authentication），双因认证或多因认证，这需要用户提供一个唯一的可信设备，比如用户的手机，然后通过验证手机短信，或是像 Google Authenticator 这样的动态口令来完成。这样的安全级别已经算是比较高了。如果能够再加上经常性的变更密码，那么密全级别就更好了。

另外，一些公司还使用了生物密码来进行用户的身份验证，比如人脸识别。但是，我个人觉得人脸识别或是生物识别是比较糟糕的方式，因为：

目前能被验证的生物信息（如人脸和指纹）太容易被别人获得和伪造了。
这样东西不能被变更和吊销，密码可以被吊销和重置，人脸则不能。

密钥对和证书

密码可以解决身证认证的问题有很多问题，最重要的一个问题就是，你要把你的密码提供给对方，对方才能验证你的身份。你不可能把你的密码提供给全世界的人吧，这样的话，全世界的人都有你的密码了，那么任何人都能变成你了。所以，用户密码这个事只能存在于权威机构和普通用户之间，不能存在于普遍应用中。所以，这里需要使用更好的解决方案。

使用 ECC（ Elliptic-Curve Cryptography）椭圆曲线密码术，可以通过一个“密钥对”进行非对称加密。这种技术，在对信息进行加密和解密时，使用两个不同的密钥，其中一个用来做加密，另一个做解密。这样一来，我们就可以把其中一个密钥公布出去，称之为公钥，另一个密钥私密地保管好，称之为私钥。

比如，我用我的私钥加密信息，然后，我把这个私钥所配对的公钥发布给所有人，大家都用公钥解密信息，不用我的公钥你解密不了这个信息。这样一来，就可以保证这个信息是我发出来的，不但保证了信息安全，还完成了身份认证。

这样的现实案例一般用于网站，也就是用户得要知道我访问的这个网站是真实的，不是别人做的。因为 DNS 很容易被 hack，你连上一个不可信的网络，这个网络里的 DNS 把这个网站的 IP 地址解析成什么就是什么了。但是有了这个加密的机制后，网站把自己的信息加密后连同公钥给到访问者，访问解密后就知道是不是这个网站了。

但是，这里还是会有一个很严重的问题，那就是中间人攻击。如下图所示：

中间人 Chad 把伪装成 Bob 向 Alice 要信息，然后，再伪装成 Alice 对 Bob 说，这就是 Alice 的公钥，于是 Bob 也无法验证是不是 Alice 的公钥，因为公钥里就是一堆乱七八糟的数据，我们完全不能分辨哪个公钥属于 Alice 的。试想，如果我们收到声称属于银行的密钥。我们怎么知道它确实属于你的银行？

这里的答案就是 使用数字证书。证书跟我们的身份证非常类似，其需要一个可信机构来颁发和验证的。这个证书机构 CA（Certificate Authority）是一个是大家都相信的权威机构，他用他的人品保证（当然一般会被严格管理和审计），CA 机构同样使用这样的非对称加密的技术来完成颁发和验证的事。下图展示了这一过程。

说明一下上面这个图：

为了解决公钥认证的问题的，我们需要一个权威的CA 机构。
Alice 把自己的信息（姓名、组织，地址，电邮，网址等）和自己的公钥打包成一个 CSR 的文件，发给 CA 机构，
CA 机构会来找 Alice 做物理世界的认证，如果通过后，就会用自己的机构私钥，把CSR 变成一个签名证书。
Bob 同学拿到 Alice 的证书，用 CA 机构的公钥解密后，得到 Alice 的公钥
后面就可以签证信息是否来自 Alice 了。

是的，这个过程就是在“套娃”，这种证书机构还可以给下级的证书机构发证，于是就会一层套一层地，形成一个证书链，顶层的叫根证书，你得绝对信任之。对于验证证书真实性的客户端，它需要能够验证链中所有 CA 的签名，这意味着客户端需要访问链中所有 CA 的证书。

证书生成过程演示

并不是所有的场景都需要向这些大型的 CA 机构申请公钥证书，在任何一个企业，组织或是团体内都可以自己形这样的“小王国”，也就是说，你可以自行生成这样的证书，只需要你自己保证自己的生成证书的私钥的安全，以及不需要扩散到整个互联网。下面，我们用 openssl命令来演示这个过程。

1）生成 CA 的证书（公钥） ca.crt 和私钥 ca.key

openssl req -newkey rsa:2048 \
    -new -nodes -x509 \
    -days 365 \
    -out ca.crt \
    -keyout ca.key \
    -subj "/C=SO/ST=Earth/L=Mountain/O=CoolShell/OU=HQ/CN=localhost"

2) 生成 alice 的私钥

openssl genrsa -out alice.key 2048

3）生成 Alice 的 CSR – Certificate Signing Request

openssl req -new -key alice.key 365 -out alice.csr \
    -subj "/C=CN/ST=Beijing/L=Haidian/O=CoolShell/OU=Test/CN=localhost.alice"

4）使用 CA 给 Alice 签名证书

openssl x509  -req -in alice.csr \
    -extfile <(printf "subjectAltName=DNS:localhost.alice") \ 
    -CA ca.crt -CAkey ca.key  \
    -days 365 -sha256 -CAcreateserial \
    -out alice.crt

双向认证 mTLS

上面，我们说的基本上都是单向认证，大量的场景都是确保用户方访问的是真正的服务方，如：银行，电商网站，等。这样可以保证用户不会被钓鱼网站或是中间人攻击。但是，很多时候，我们也是需要双向认证的。下面是一个典型的场景——微信支付和商户间交互

用户到商家那边买东西，商家要求用户进行支付。
用户选择了微信支付，于是，界面从商户侧切到了微信侧
微信那边支付完成后，商户这边收到微信那边支付完成的通知，于是开始发货。

这个过程中有件事非常重要——就是微信通知商户支付完成的时候。

微信得确保通知到的就是用户所支付商户，而不是别个。
商户也得要能确认，来通知我的就是微信，不是别人。

一般来说，微信会给商户一个 AppID和一个 AppSerct，用这个来确保是我认证过的商户来调用我，然后，需要商户在自己的系统里填一个回调的 URL，并通过平台设置的 key来做 MD5/HMAC的签名来确保是官方的回调。这都是在《 HTTP API 认证授权术》中提到过的技术，是相对传统的技术。

如今， mTLS是确保云原生应用程序中服务之间的通信安全的首选协议。也就是双向认证。

传统的 TLS 认证过程是：

客户端连接到服务器
服务器提供其 TLS 证书
客户端验证服务器的证书
客户端和服务器通过加密的 TLS 连接交换信息

在 mTLS 中，客户端和服务器都有一个证书，双方都使用他们的公钥/私钥对进行身份验证。与常规 TLS 相比，mTLS 中有额外的步骤来验证双方（以 粗体显示的额外步骤）：

客户端连接到服务器
服务器提供其 TLS 证书
客户端验证服务器的证书
客户端出示其 TLS 证书
服务器验证客户端的证书
服务器授予访问权限
客户端和服务器通过加密的 TLS 连接交换信息

mTLS 需要“根”TLS 证书；这我们自己来完成证书颁发机构的职责。授权客户端和服务器使用的证书必须与此根证书相对应。根证书是自签名的，这意味着我们需要自己创建它。（注：此方法不适用于公共 Internet 上的单向 TLS，因为外部证书颁发机构必须颁发这些证书）

那么，为什么整个互联网上都用了 TLS 了，为什么不升级一下使用 mTLS？这里有两方面的原因：

公共互联网上要解决的问题是：A) 确保用户访问到的是正确的网站，而不是钓鱼网站。B）网站传输的内容是安全和私密且不会被篡改的。
将 TLS 证书分发到所有最终用户设备将非常困难。生成、管理和验证为此所需的数十亿个证书几乎是不可能的任务。

在较小的范围内，mTLS 对于单个组织非常有用且非常实用，尤其是当这些组织采用零信任方法来确保网络安全时。由于默认情况下零信任方法不信任任何用户、设备或请求，因此组织必须能够在每次尝试访问网络中的任何点时对每个用户、设备和请求进行身份验证。mTLS 通过对用户进行身份验证和设备验证来帮助实现这一目标。

关于 mTLS，这里有一个我用 Golang 写的示例 – https://github.com/haoel/mTLS，大家可以参考一下。

P.S. 本文图版中的卡司来自安全圈的标准 Cast，参看 Alice and Bob。

（全文完）

关注CoolShell微信公众账号和微信小程序

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

The post 网络数字身份认证术 first appeared on 酷壳 - CoolShell.

打动用户的 12 条 UI 设计法则

Sun, 10 Oct 2021 20:39:05 CST

前言：不少设计师看到好看的设计，第一时间是保存起来，或粗略浏览、或不再过问。但草草地浏览并不意味着我们真正理解这样设计的内涵，或者真正了解设计背后的技巧。要让用户动心，还需要了解设计心理学，从用户心理去引导用户行为。今天设计达人分享的这篇文章，分别从格式塔心理学、色彩心理、形状心理学角度进行案例分析，希望能给你一些帮助！

1. 连续性法则

连续性的元素排列形成组织关系，能够让阅读变得更加的连贯和清晰。目的是为了驱动用户完成我们想要的操作，如左滑可以看到更多卡片。通过连续性的方式进行引导告知，用户隐藏的部分。例如：导航分类、列表、轮播图、卡片中都有运用。提示了用户查看更多信息，在轮播图中经常会用到这个方法设计。

2. 相似性法则

我们的视觉感官会把相似的元素联系在一起，主观认为这些元素有同样的意图，所以在设计相同状态或相同功能元素时，我们需要保持视觉的统一性，让用户认为是一样的功能按钮或模块。看到导航栏下方的图标，因为形状大小一致，用户会认为他们的功能属于同一类型，并且可以点击。

3. 封闭性法则

在我们看到一个残缺的图形时，我们会脑补出它完整的样子。这种表现方式经常会用到 LOGO 的设计中，同样在界面设计中也会运用。例如图标、可视化图表等。

4. 邻近性法则

我们的眼睛会把相邻的内容组成一组，从而减少内容带来的阅读压力。这是设计中必不可少的排版方法，特别是复杂的信息流页面，经常会运用邻近性方法进行设计，保证信息传递更有条理性。在设计的时候，利用间距将元素组合在一起，这种方法通常会运用在内容信息、卡片、横幅中。

5. 对称性法则

对称的图形会让我们感觉稳定可靠。我在界面设计中为了提高稳定性会运用对称法则进行设计。但是过度使用对称会让人感觉单调和乏味，所有需要合理运用对称性法则，在适当时候出现。这个方法通常会运用在焦点图、产品展示、列表、导航中。

6. 组合性法则

为了提高页面中内容关系，会进行视觉性分组。采用卡片框的形式进行区分，从而让多种元素整合成块，让布局更加的规整。组合性法则经常会用到内容、列表的设计中。

7. 同属性法则

在同一个方向移动的元素，会感觉到它们是有联系的。如点击折叠菜单后，同时出现的多个元素，它们是有联系的。这样的规律可以有效建立元素的关系，从心理上认为它们的属性一致，这样的方式经常会出现在导航、下拉菜单、折叠菜单中。

8. 焦点性法则

通过加强对比度或对元素放大来凸显重点，从而吸引眼球。目的是为了让用户聚焦到我们想让他看到的信息上，从而引导用户关注重点信息。特别是在详情页中或提示性框中，会使用 “焦点法” 进行设计。

9. 生理性法则

越真实的感观越容易被接受，同样也能吸引注意力。就像文字不如图片好阅读，而图片不如视频更加直观一样。通过图像可以多感知传递信息，所以很多产品会用照片或视频来激发用户购买。为了让体验更有趣，还会通过震动或音效来强化感知。照片对比图能让用户直观的看到整容前后的效果，激发整容的欲望。

10. 隔离性法则

人的视线容易被不同元素或突出元素吸引，并且能很快的记住。这个法则很容易与焦点法则相混淆。不同的地方是，应用这个规则的元素往往是独立存在的，并没有额外的功能和信息。

11. 色彩心理学

颜色对我们的潜意识有特别的影响。不同性别、不同宗教、不同文化的人对色彩的看法也不同。例如红色代表的是错误、绿色代表了成功、蓝色代表着进行中、黄色代表活力同时隐含着危险感。

12. 形状心理学

形状是所有设计中无法忽略的关键因素。研究表明，每种形状有着它们的含义。和颜色一样，人的潜意识对不同的形状也有不同的反应。

方形和矩形

由于我们会看的物体墙壁、家具、图书都是方形和矩形的形状，潜意识会认为直角带来可靠和安全的感觉。但过度使用会造成 “死板” 的感觉，所以在活泼的产品调性中避免使用。给人的感受：力量、勇气、安全、可靠

三角形

三角形给人的感受是充满阳刚之气、活力和动感。三角形的的夹角还会吸引用户的视线，起到指引方向的左右。朝向上的三角会让人安心，而相反的倒三角会感觉到危险。给人的感受：权利、运动、稳定、危险。

圆形和椭圆

圆形会给人带来永恒的感觉，由于没有尖角，会看起来更加的温和柔软，好亲近。所以在社交产品或女性产品中经常使用圆形。同时看到圆形我们会联想到宇宙、太阳、地球元素，因此圆形会给人带来科技感。另外椭圆相对圆形更加有趣味性，比圆形更加有活力。给人的感受：神秘、亲近、宇宙

平行线

平行线和矩形一样给人感觉比较的稳定，相对矩形层次更加的丰富。平行线给人的感受是冷静，所以多用于硬件设计或工具类的产品中。给人的感受：冷静、稳重

垂直线

和平行线不同，垂直的线条会让人感觉高大。人心理面对高大的物体的时候都会感觉到侵略感。所以在制作友好的界面中我们很少用到。给人的感受：力量、侵略性、霸道。

对角线

对角线的设计会打破安静的设计，带给我们动感和活力。所以很多运动类的产品会使用到对角线的设计。给人的感受：活力、成长、动力。今天分享的 12 个心理学法则，它们本质都是一样的，就是通过设计引导帮助用户。通过法则我们可以影响用户的行为，管控好用户的使用路径，达到设计的目的。好的设计源自细节，也源自用户心理。注重用户的反馈，避免糟糕的体验，积极引导用户情绪，才能做出更好的产品。作者 | micu 设计原文网址：https://www.zcool.com.cn/article/ZMTI2OTUzMg==.html

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

有赞保险业务的分析与架构设计

Mon, 13 Sep 2021 15:54:45 CST

1、背景

有赞微商城为商家提供了全行业全场景的电商解决方案，帮助商家在社交电商、直播电商等场景下快速布局。在整个交易流程中，对退货时运费减免的支持已成为了电商场景的标配。有赞也提供了 “退货包运费” 产品来满足消费者及商家在此场景下的诉求。

本文从“退货包运费”这个产品出发，分析保险业务的特征，介绍有赞保险业务系统的架构设计。

2、退货包运费及保险业务分析

在目前消费者权益保护法对消费者网购支持的大背景下，许多类目的商品都能支持七天无理由退货。由此也衍生出退货时物流运费支出的一些争议，给消费者和商家带来困扰。“退货包运费”产品的出现正是为电商业务解决在退货流程中这类问题，从而提升购物体验。

2.1 产品价值

从消费者角度，退货运费减免信息的透出能让消费者得到承诺，并在实际发生退货退款时减少运费支出。
站在商家角度，产品能降低消费者网购时的选择成本，提高下单转化率，以及有效地减少在售后处理上的人力投入。

2.2 产品流程分析

当商家开通“退货包运费”后，其服务开始作用在交易链路上：

消费者支付前，在商品详情页及下单确认页里准确地判断并展示服务内容。
消费者支付后，在订单详页面的“退货包运费”一栏中显示当前的服务状态及内容。
商家发货后，收取商家一些的费用，向保险公司投保，生成保单，服务进入生效阶段。
退货退款时，如果消费者选择的是上门取件，可以直接抵扣退货运费。如果是自行寄回，消费者需先行支付运费，退款完成后，保司自动赔付给消费者。

2.3 产品风险管控分析

为了避免一些骗保、刷单、恶意退款、薅羊毛等不良行为影响产品的正常运营，“退货包运费”会在关键流程节点接入有赞强大的风控体系来保障产品的健康发展，比如：根据不同的风险因素适当调整服务费率、服务前的风控审核、申请赔付前的审核等。

2.4 保险业务分析

“退货包运费”是一种保险类的业务，消费者或商家支付较低费用，约定了在小概率风险事件（退货）发生时，对于被保的一方（消费者）发起赔付，达到减免退货物流运费的目的。目前市场上许多保险公司（下简称：保司）有对应成熟的保险产品，有赞也与保司合作一起为消费者和商家提供服务。

有赞保险类业务的能力要与保司的能力匹配，而保险这种业务形态已经比较成熟，在《中华人民共和国保险法》里对于保险业务活动进行了规范，从中我们能看到保险业的基本业务活动。

“保险，是指投保人（注1）根据合同约定，向保险人（注2）支付保险费，保险人对于合同约定的可能发生的事故因其发生所造成的财产损失承担赔偿保险金责任，或者当被保险人（注3）死亡、伤残、疾病或者达到合同约定的年龄、期限等条件时承担给付保险金责任的商业保险行为”。

保险合同是保险活动的载体，是投保人与保险人约定保险权利义务关系的协议。围绕保险合同的签订、变更、终止以及当事人权利义务的履行，都是保险业务的范畴。保险分为财产保险和人身保险，在电商场景中，我们一般涉及到的是财产保险。生命周期见下图：

保险合同（下简称：保单）里一般包含了以下内容：

保险人的名称和住所；
投保人、被保险人的姓名或者名称、住所，以及人身保险的受益人(注4)的姓名或者名称、住所；
保险标的；
保险责任和责任免除；
保险期间和保险责任开始时间；
保险金额（注5）；
保险费以及支付办法；
保险金赔偿或者给付办法；
违约责任和争议处理；
订立合同的年、月、日。

在保单的有效期里，可以对保单进行变更、终止、修改条款等，依据保单中条款申请理赔。

3、架构设计

3.1 业务架构设计

通过上面的价值及流程分析，“退货包运费”产品能分解出以下一些流程活动：

服务管理方面：提供服务的生命周期管理，如开通、关闭服务。对于有赞而言，要对已开通的商家做风险管控，还需要支持冻结、解冻、清退等操作，商家也能查看到服务费率的历史变更情况。
服务单管理方面：可服务内容的查询，服务单的查询，服务单的生命周期管理，比如下单、生效、抵扣试算，抵扣申请，自动申请理赔，理赔修改。

这些流程活动依赖保险领域的业务能力来支撑，具体见下图：

3.2 技术架构设计

在应用设计中，我们将整个保险类业务的应用架构分为业务服务层、领域服务层、组件层、依赖层：

业务服务层：对接有赞生态SAAS业务，提供“退货包运费”服务，即感知交易的全流程，推进服务单据状态流转。根据商家的经营情况，批量更新费率。
领域服务层：对上层提供标准承保、理赔的服务。另外，为支持上层不同的保险类产品，需要为不同的产品配置不同收费规则、管理对应的保司渠道。
组件层：提供领域服务的可复用的基础能力，比如向保司投保理赔、风控校验审核、业务校验、支付退款等。
依赖层：组件服务里主要依赖了一些中台性质的服务，如店铺、会员、交易、支付、风控。

对于领域服务层的设计，适合应用领域驱动设计(简称：DDD）这种建模方法。从上面的保险领域分析中，我们梳理出几个主要的领域模型：

领域服务层主要围绕保单、理赔单对外提供服务。

支撑子域有：

产品中心：定义一个保险类产品，包括产品的服务明细条款，协议模板，协议约定校验，保险人信息，收付款方式等。
标的管理：管理保险标的相关的信息，在“退货包运费”里就是退货运费相关信息，如订单信息，退货商品的信息、物流信息等。
渠道管理：出于产品成本及业务稳定性考虑，一个保险产品有多个保司渠道备份，渠道管理负责渠道的定义，与保司接口适配，主要有投保，理赔，保单查询等。

通用子域有：

计费管理：用于支持产品、商家、消费者、商品等多维度的费率配置及对订单收费计算。
产品-渠道路由：支持产品下，根据权重、稳定性、费率、最低单量、定制等不同维度的衡量标准选出匹配的渠道。

领域服务层之下，是支撑这些服务的组件：

业务规则相关：投保校验、理赔校验。
资金相关：保费收取、保费退回、投保记账、理赔记账。
渠道相关：渠道投保、渠道理赔。
风控相关：风控投保审核、风控理赔审核。

应用架构如下图：

4、后记

在有赞电商生态中，还有许多保险类业务可以切入的场景，比如准时发货保障，针对美妆类过敏包赔的承诺，对生鲜、3C类的损坏赔付等。这些场景对有赞保险业务的能力建设提出了更高的要求，保险系统将向高复用、易扩展的方向继续演进，以支持业务的拓展。

注：

投保人是指与保险人订立保险合同，并按照合同约定负有支付保险费义务的人。
保险人是指与投保人订立保险合同，并按照合同约定承担赔偿或者给付保险金责任的保险公司。
被保险人是指其财产或者人身受保险合同保障，享有保险金请求权的人。投保人可以为被保险人。
受益人是指人身保险合同中由被保险人或者投保人指定的享有保险金请求权的人。投保人、被保险人可以为受益人。
保险金额是指保险人承担赔偿或者给付保险金责任的最高限额。

自建一个简易的OpenAPI网关

Thu, 16 Jul 2020 03:30:00 CST

网关（API Gateway）是请求流量的唯一入口，可以适配各类渠道和业务，处理各种协议接入、路由与报文转换、同步异步调用等，来管理 API 接口和进行请求流量控制，在微服务架构中，网关尤为重要。

背景

当然，现在已有很多开源软件，如 Kong、 Gravitee、 Zuul。

这些开源网关固然功能齐全，但对于我们业务来说，有点太重了，我们有部分定制化需求，为此我们自建了一个轻量级的 OpenAPI 网关，主要供第三方渠道对接使用。

简介

功能特性

接口鉴权

请求 5s 自动过期
参数 md5 签名
模块粒度的权限控制

接口版本控制

支持转发到不同服务
支持转发到同一个服务不同接口

事件回调

事件订阅
最大重试 3 次
重试时间采用衰减策略（30s、60s、180s）

系统架构

从第三方请求 API 链路来说，第三方渠道通过 HTTP 协议请求 OpenAPI 网关，网关再将请求转发到对应的内部服务端口，这些端口层通过 gRPC 调用请求到服务层，处理完请求后依次返回。

从事件回调请求链路来说，服务层通过 HTTP 协议发起事件回调请求到 OpenAPI 网关，并立即返回成功。OpenAPI 网关异步完成第三方渠道事件回调请求。

实现

网关配置

由于网关存在内部服务和第三方渠道配置，更为了实现配置的热更新，我们采用了 ETCD 存储配置，存储格式为 JSON。

配置分类

配置分为以下 3 类：

第三方 AppId 配置
内外 API 映射关系
内部服务地址

配置结构

a、第三方 AppId 配置

b、内部服务地址

c、内外 API 映射关系

配置更新

利用 ETCD 的 watch 监听，可以轻易实现配置的热更新。

当然也还是需要主动拉取配置的情况，如重启服务的时候。

API 接口

第三方调用 API 接口的时序，大致如下：

参数格式

为了简化对接流程，我们统一了 API 接口的请求参数格式。请求方式支持 POST 或者 GET。

接口签名

签名采用 md5 加密方式，算法可描述为：

1、将参数 p、m、a、t、v、ak、secret 的值按顺序拼接，得到字符串；
2、md5 第 1 步的字符串并截取前 16 位，得到新字符串；
3、将第 2 步的字符串转化为小写，即为签名；

PHP 版的请求，如下：

$appId = 'app id';     
$appSecret = 'app secret';     
$api = 'api method';     
     
// 业务参数     
$businessParams = [     
  'orderId' => '123123132',     
];     
     
$time = time();     
$params = [     
  'p'  => json_encode($businessParams),     
  'm'  => 'inquiry',     
  'a'  => $api,     
  't'  => $time,     
  'v'  => 1,     
  'ak' => $appId,     
];     
     
$signStr = implode('', array_values($params)) . $appSecret;     
$sign = strtolower(substr(md5($signStr), 0, 16));     
     
$params['s'] = $sign;

接口版本控制

不同的接口版本，可以转发请求到不同的服务，或同一个服务的不同接口。

事件回调

通过事件回调机制，第三方可以订阅自己关注的事件。

对接接入

渠道接入

只需要配置第三方 AppId 信息，包括 secret、回调地址、模块权限。

即，需要在 ETCD 执行如下操作：

$ etcdctl set /openapi/app/baidu '{     
    "Id": "baidu",     
    "Secret": "00cf2dcbf8fb6e73bc8de50a8c64880f",     
    "Modules": {     
        "inquiry": {     
            "module": "inquiry",     
            "CallBack": "http://www.baidu.com"     
        }     
    }     
}'

服务接入

a、配置内部服务地址

即，需要在 ETCD 执行如下操作：

$ etcdctl set /openapi/backend/form_openapi '{     
    "type": "form",     
    "Url": "http://med-ih-openapi.app.svc.cluster.local"     
}'

b、配置内外 API 映射关系

同样，需要在 ETCD 执行如下操作：

$ etcdctl set /openapi/api/inquiry/createMedicine.v2 '{     
    "Module": "inquiry",     
    "Method": "createMedicine",     
    "Backend": "form_openapi",     
    "ApiParams": {     
        "path": "inquiry/medicine-clinic/create"     
    }     
}'

c、接入事件回调

接入服务也需要按照第三方接入方式，并申请 AppId。回调业务参数约定为：

Golang 版本的接入，如下：

const (     
AppId = "__inquiry"     
AppSecret = "xxxxxxxxxx"     
Version = "1"     
)     
     
type CallbackReq struct {     
TargetAppId string                 //目标APP Id     
Module      string                 //目标模块     
Event       string                 //事件     
Params      map[string]interface{} //参数     
}     
     
func generateData(req CallbackReq) map[string]string {     
    params, _ := json.Marshal(req.Params)     
p := map[string]interface{}{     
"ak": req.TargetAppId,     
"m":  req.Module,     
"e":  req.Event,     
"p":  string(params),     
}     
     
pStr, _ := json.Marshal(p)     
postParams := map[string]string{     
"p":  string(pStr),     
"m":  "callback",     
"a":  "callback",     
"t":  fmt.Sprintf("%d", time.Now().Unix()),     
"v":  Version,     
"ak": AppId,     
}     
     
postParams["s"] = sign(getSignData(postParams) + AppSecret)     
     
return postParams     
}     
     
func getSignData(params map[string]string) string {     
return strings.Join([]string{params["p"], params["m"], params["a"], params["t"], params["v"], params["ak"]}, "")     
}     
     
func sign(str string) string {     
return strings.ToLower(utils.Md5(str)[0:16])     
}

未来规划

后台支持配置 AppId
事件回调失败请求支持手动重试
请求限流

一个 Hybrid SDK 设计与实现

Mon, 28 Jun 2021 11:12:12 CST

随着移动浪潮的兴起，各种 App 层出不穷，极速发展的业务拓展提升了团队对开发效率的要求，这个时候纯粹使用 Native 开发技术成本难免会更高一点。而 H5 的低成本、高效率、跨平台等特性马上被利用起来了，形成一种新的开发模式： Hybrid App

作为一种混合开发的模式，Hybrid App 底层依赖于 Native 提供的容器（Webview），上层使用各种前端技术完成业务开发（现在三足鼎立的 Vue、React、Angular），底层透明化、上层多样化。这种场景非常有利于前端介入，非常适合业务的快速迭代。于是 Hybrid 火了。

大道理谁都懂，但是按照我知道的情况，还是有非常多的人和公司在 Hybrid 这一块并没有做的很好，所以我将我的经验做一个总结，希望可以帮助广大开发者的技术选型有所帮助

Hybrid 的一个现状

可能早期都是 PC 端的网页开发，随着移动互联网的发展，iOS、Android 智能手机的普及，非常多的业务和场景都从 PC 端转移到移动端。开始有前端开发者为移动端开发网页。这样子早期资源打包到 Native App 中会造成应用包体积的增大。越来越多的业务开始用 H5 尝试，这样子难免会需要一个需要访问 Native 功能的地方，这样子可能早期就是懂点前端技术的 Native 开发者自己封装或者暴露 Native 能力给 JS 端，等业务较多的时候者样子很明显不现实，就需要专门的 Hybrid 团队做这个事情；量大了，就需要规矩，就需要规范。

总结：

Hybrid 开发效率高、跨平台、低成本
Hybrid 从业务上讲，没有版本问题，有 Bug 可以及时修复

Hybrid 在大量应用的时候就需要一定的规范，那么本文将讨论一个 Hybrid 的设计知识。

Hybrid 、Native、前端各自的工作是什么
Hybrid 交互接口如何设计
Hybrid 的 Header 如何设计
Hybrid 的如何设计目录结构以及增量机制如何实现
资源缓存策略，白屏问题...

Native 与前端分工

在做 Hybird 架构设计之前我们需要分清 Native 与前端的界限。首先 Native 提供的是宿主环境，要合理利用 Native 提供的能力，要实现通用的 Hybrid 架构，站在大前端的视觉，我觉得需要考虑以下核心设计问题。

交互设计

Hybrid 架构设计的第一要考虑的问题就是如何设计前端与 Native 的交互，如果这块设计不好会对后续的开发、前端框架的维护造成深远影响。并且这种影响是不可逆、积重难返。所以前期需要前端与 Native 好好配合、提供通用的接口。比如

Native UI 组件、Header 组件、消息类组件
通讯录、系统、设备信息读取接口
H5 与 Native 的互相跳转。比如 H5 如何跳转到一个 Native 页面，H5 如何新开 Webview 并做动画跳转到另一个 H5 页面

账号信息设计

账号系统是重要且无法避免的，Native 需要设计良好安全的身份验证机制，保证这块对业务开发者足够透明，打通账户体系

Hybrid 开发调试

功能设计、编码完并不是真正结束，Native 与前端需要商量出一套可开发调试的模型，不然很多业务开发的工作难以继续。

iOS调试技巧

Android 调试技巧：

App 中开启 Webview 调试(WebView.setWebContentsDebuggingEnabled(true);　)
chrome 浏览器输入 chrome://inspect/#devices 访问可以调试的 webview 列表
需要翻墙的环境

Hybrid 交互设计

Hybrid 交互无非是 Native 调用 H5 页面JS 方法，或者 H5 页面通过 JS 调 Native 提供的接口。2者通信的桥梁是 Webview。
业界主流的通信方法：1.桥接对象（时机问题，不太主张这种方式）；2.自定义 Url scheme

App 自身定义了 url scheme，将自定义的 url 注册到调度中心，例如
weixin:// 可以打开微信。

关于 Url scheme 如果不太清楚可以看看这篇文章

JS to Native

Native 在每个版本都会提供一些 Api，前端会有一个对应的框架团队对其封装，释放业务接口。举例

  SDGHybrid.http.get()  // 向业务服务器拿数据
SDGHybrid.http.post() // 向业务服务器提交数据
SDGHybrid.http.sign() // 计算签名
SDGHybrid.http.getUA()  // 获取UserAgent

  SDGHybridReady(function(arg){
  SDGHybrid.http.post({
    url: arg.baseurl + '/feedback',
    params:{
      title: '点菜很慢',
      content: '服务差'
    },
    success: (data) => {
      renderUI(data);
    },
    fail: (err) => {
      console.log(err);
    }
  })
})

前端框架定义了一个全局变量 SDGHybrid 作为 Native 与前端交互的桥梁，前端可以通过这个对象获得访问 Native 的能力

Api 交互

调用 Native Api 接口的方式和使用传统的 Ajax 调用服务器，或者 Native 的网络请求提供的接口相似

所以我们需要封装的就是模拟创建一个类似 Ajax 模型的 Native 请求。

格式约定

交互的第一步是设计数据格式。这里分为请求数据格式与响应数据格式，参考 Ajax 模型：

  $.ajax({
  type: "GET",
  url: "test.json",
  data: {username:$("#username").val(), content:$("#content").val()},
  dataType: "json",
  success: function(data){
    renderUI(data);           
  }
});

  $.ajax(options) => XMLHTTPRequest
type(默认值：GET)，HTTP请求方法（GET|POST|DELETE|...）
url(默认值：当前url)，请求的url地址
data(默认值：'') 请求中的数据如果是字符串则不变，如果为Object，则需要转换为String，含有中文则会encodeURI

所以 Hybrid 中的请求模型为：

  requestHybrid({
  // H5 请求由 Native 完成
  tagname: 'NativeRequest',
  // 请求参数
  param: requestObject,
  // 结果的回调
  callback: function (data) {
    renderUI(data);
  }
});

这个方法会形成一个 URL，比如：
SDGHybrid://NativeRequest?t=1545840397616&callback=Hybrid_1545840397616&param=%7B%22url%22%3A%22https%3A%2F%2Fwww.datacubr.com%2FApi%2FSearchInfo%2FgetLawsInfo%22%2C%22params%22%3A%7B%22key%22%3A%22%22%2C%22page%22%3A1%2C%22encryption%22%3A1%7D%2C%22Hybrid_Request_Method%22%3A0%7D

Native 的 webview 环境可以监控内部任何的资源请求，判断如果是 SDGHybrid 则分发事件，处理结束可能会携带参数，参数需要先 urldecode 然后将结果数据通过 Webview 获取 window 对象中的 callback（Hybrid_时间戳）

数据返回的格式和普通的接口返回格式类似

  {
  errno: 1,
  message: 'App版本过低，请升级App版本',
  data: {}
}

这里注意：真实数据在 data 节点中。如果 errno 不为0，则需要提示 message。

简易版本代码实现。

  //通用的 Hybrid call Native
window.SDGbrHybrid = window.SDGbrHybrid || {};
var loadURL = function (url) {
    var iframe = document.createElement('iframe');
    iframe.style.display = "none";
    iframe.style.width = '1px';
    iframe.style.height = '1px';
    iframe.src = url;
    document.body.appendChild(iframe);
    setTimeout(function () {
        iframe.remove();
    }, 100);
};

var _getHybridUrl = function (params) {
    var paramStr = '', url = 'SDGHybrid://';
    url += params.tagname + "?t=" + new Date().getTime();
    if (params.callback) {
        url += "&callback=" + params.callback;
        delete params.callback;
    }

    if (params.param) {
        paramStr = typeof params.param == "object" ? JSON.stringify(params.param) : params.param;
        url += "&param=" + encodeURIComponent(paramStr);
    }
    return url;
};


var requestHybrid = function (params) {
    //生成随机函数
    var tt = (new Date().getTime());
    var t = "Hybrid_" + tt;
    var tmpFn;

    if (params.callback) {
        tmpFn = params.callback;
        params.callback = t;
        window.SDGHybrid[t] = function (data) {
            tmpFn(data);
            delete window.SDGHybrid[t];
        }
    }
    loadURL(_getHybridUrl(params));
};

//获取版本信息，约定APP的navigator.userAgent版本包含版本信息：scheme/xx.xx.xx
var getHybridInfo = function () {
    var platform_version = {};
    var na = navigator.userAgent;
    var info = na.match(/scheme\/\d\.\d\.\d/);
 
    if (info && info[0]) {
      info = info[0].split('/');
      if (info && info.length == 2) {
        platform_version.platform = info[0];
        platform_version.version = info[1];
      }
    }
    return platform_version;
};

Native 对于 H5 来说有个 Webview 容器，框架&&底层不太关心 H5 的业务实现，所以真实业务中 Native 调用 H5 场景较少。

上面的网络访问 Native 代码（iOS为例）

  typedef NS_ENUM(NSInteger){
    Hybrid_Request_Method_Post = 0,
    Hybrid_Request_Method_Get = 1
} Hybrid_Request_Method;

@interface RequestModel : NSObject

@property (nonatomic, strong) NSString *url;
@property (nonatomic, assign) Hybrid_Request_Method Hybrid_Request_Method;
@property (nonatomic, strong) NSDictionary *params;

@end


@interface HybridRequest : NSObject


+ (void)requestWithNative:(RequestModel *)requestModel hybridRequestSuccess:(void (^)(id responseObject))success hybridRequestfail:(void (^)(void))fail;

+ (void)requestWithNative:(RequestModel *)requestModel hybridRequestSuccess:(void (^)(id responseObject))success hybridRequestfail:(void (^)(void))fail{
    //处理请求不全的情况
    NSAssert(requestModel || success || fail, @"Something goes wrong");
    
    NSString *url = requestModel.url;
    NSDictionary *params = requestModel.params;
    if (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Get) {
        [AFNetPackage getJSONWithUrl:url parameters:params success:^(id responseObject) {
            success(responseObject);
        } fail:^{
            fail();
        }];
    }
    else if (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Post) {
        [AFNetPackage postJSONWithUrl:url parameters:params success:^(id responseObject) {
            success(responseObject);
        } fail:^{
            fail();
        }];
    }
}

常用交互 Api

良好的交互设计是第一步，在真实业务开发中有一些 Api 一定会由应用场景。

跳转

跳转是 Hybrid 必用的 Api 之一，对前端来说有以下情况：

页面内跳转，与 Hybrid 无关
H5 跳转 Native 界面
H5 新开 Webview 跳转 H5 页面，一般动画切换页面
如果使用动画，按照业务来说分为前进、后退。forward & backword，规定如下，首先是 H5 跳 Native 某个页面

  //H5跳Native页面
//=>SDGHybrid://forward?t=1446297487682&param=%7B%22topage%22%3A%22home%22%2C%22type%22%3A%22h2n%22%2C%22data2%22%3A2%7D
requestHybrid({
   tagname: 'forward',
   param: {
     // 要去到的页面
     topage: 'home',
     // 跳转方式，H5跳Native
     type: 'native',
     // 其它参数
     data2: 2
   }
});

H5 页面要去 Native 某个页面

  //=>SDGHybrid://forward?t=1446297653344&param=%7B%22topage%22%253A%22Goods%252Fdetail%20%20%22%252C%22type%22%253A%22h2n%22%252C%22id%22%253A20151031%7D
requestHybrid({
  tagname: 'forward',
  param: {
    // 要去到的页面
    topage: 'Goods/detail',
    // 跳转方式，H5跳Native
    type: 'native',
    // 其它参数
    id: 20151031
  }
});

H5 新开 Webview 的方式去跳转 H5

  requestHybrid({
  tagname: 'forward',
  param: {
    // 要去到的页面，首先找到goods频道，然后定位到detail模块
    topage: 'goods/detail  ',
    //跳转方式，H5新开Webview跳转，最后装载H5页面
    type: 'webview',
    //其它参数
    id: 20151031
  }
});

back 与 forward 一致，可能会有 animatetype 参数决定页面切换的时候的动画效果。真实使用的时候可能会全局封装方法去忽略 tagname 细节。

Header 组件的设计

Native 每次改动都比较“慢”，所以类似 Header 就很需要。

主流容器都是这么做的，比如微信、手机百度、携程
没有 Header 一旦出现网络错误或者白屏，App 将陷入假死状态

PS： Native 打开 H5，如果 300ms 没有响应则需要 loading 组件，避免白屏
因为 H5 App 本身就有 Header 组件，站在前端框架层来说，需要确保业务代码是一致的，所有的差异需要在框架层做到透明化，简单来说 Header 的设计需要遵循：

H5 Header 组件与 Native 提供的 Header 组件使用调用层接口一致
前端框架层根据环境判断选择应该使用 H5 的 Header 组件抑或 Native 的 Header 组件

一般来说 Header 组件需要完成以下功能：

Header 左侧与右侧可配置，显示为文字或者图标（这里要求 Header 实现主流图标，并且也可由业务控制图标），并需要控制其点击回调
Header 的 title 可设置为单标题或者主标题、子标题类型，并且可配置 lefticon 与 righticon（icon居中）
满足一些特殊配置，比如标签类 Header

所以，站在前端业务方来说，Header 的使用方式为（其中 tagname 是不允许重复的）：

   //Native以及前端框架会对特殊tagname的标识做默认回调，如果未注册callback，或者点击回调callback无返回则执行默认方法
 // back前端默认执行History.back，如果不可后退则回到指定URL，Native如果检测到不可后退则返回Naive大首页
 // home前端默认返回指定URL，Native默认返回大首页
  this.header.set({
      left: [
        {
          //如果出现value字段，则默认不使用icon
          tagname: 'back',
          value: '回退',
          //如果设置了lefticon或者righticon，则显示icon
          //native会提供常用图标icon映射，如果找不到，便会去当前业务频道专用目录获取图标
          lefticon: 'back',
          callback: function () { }
        }
     ],
     right: [
      {
        //默认icon为tagname，这里为icon
        tagname: 'search',
        callback: function () { }
      },
      //自定义图标
      {
        tagname: 'me',
        //会去hotel频道存储静态header图标资源目录搜寻该图标，没有便使用默认图标
        icon: 'hotel/me.png',
        callback: function () { }
      }
    ],
    title: 'title',
        //显示主标题，子标题的场景
    title: ['title', 'subtitle'], 
    //定制化title
    title: {
      value: 'title',
      //标题右边图标
      righticon: 'down', //也可以设置lefticon
      //标题类型，默认为空，设置的话需要特殊处理
      //type: 'tabs',
      //点击标题时的回调，默认为空
      callback: function () { }
    }
});

因为 Header 左边一般来说只有一个按钮，所以其对象可以使用这种形式：

  this.header.set({
  back: function () { },
    title: ''
});
//语法糖=>
this.header.set({
    left: [{
        tagname: 'back',
        callback: function(){}
    }],
  title: '',
});

为完成 Native 端的实现，这里会新增两个接口，向 Native 注册事件，以及注销事件：

  var registerHybridCallback = function (ns, name, callback) {
  if(!window.Hybrid[ns]) window.Hybrid[ns] = {};
  window.Hybrid[ns][name] = callback;
};

var unRegisterHybridCallback = function (ns) {
  if(!window.Hybrid[ns]) return;
  delete window.Hybrid[ns];
};

Native Header 组件实现：

  define([], function () {
    'use strict';

    return _.inherit({

        propertys: function () {

            this.left = [];
            this.right = [];
            this.title = {};
            this.view = null;

            this.hybridEventFlag = 'Header_Event';

        },

        //全部更新
        set: function (opts) {
            if (!opts) return;

            var left = [];
            var right = [];
            var title = {};
            var tmp = {};

            //语法糖适配
            if (opts.back) {
                tmp = { tagname: 'back' };
                if (typeof opts.back == 'string') tmp.value = opts.back;
                else if (typeof opts.back == 'function') tmp.callback = opts.back;
                else if (typeof opts.back == 'object') _.extend(tmp, opts.back);
                left.push(tmp);
            } else {
                if (opts.left) left = opts.left;
            }

            //右边按钮必须保持数据一致性
            if (typeof opts.right == 'object' && opts.right.length) right = opts.right

            if (typeof opts.title == 'string') {
                title.title = opts.title;
            } else if (_.isArray(opts.title) && opts.title.length > 1) {
                title.title = opts.title[0];
                title.subtitle = opts.title[1];
            } else if (typeof opts.title == 'object') {
                _.extend(title, opts.title);
            }

            this.left = left;
            this.right = right;
            this.title = title;
            this.view = opts.view;

            this.registerEvents();

            _.requestHybrid({
                tagname: 'updateheader',
                param: {
                    left: this.left,
                    right: this.right,
                    title: this.title
                }
            });

        },

        //注册事件，将事件存于本地
        registerEvents: function () {
            _.unRegisterHybridCallback(this.hybridEventFlag);
            this._addEvent(this.left);
            this._addEvent(this.right);
            this._addEvent(this.title);
        },

        _addEvent: function (data) {
            if (!_.isArray(data)) data = [data];
            var i, len, tmp, fn, tagname;
            var t = 'header_' + (new Date().getTime());

            for (i = 0, len = data.length; i < len; i++) {
                tmp = data[i];
                tagname = tmp.tagname || '';
                if (tmp.callback) {
                    fn = $.proxy(tmp.callback, this.view);
                    tmp.callback = t;
                    _.registerHeaderCallback(this.hybridEventFlag, t + '_' + tagname, fn);
                }
            }
        },

        //显示header
        show: function () {
            _.requestHybrid({
                tagname: 'showheader'
            });
        },

        //隐藏header
        hide: function () {
            _.requestHybrid({
                tagname: 'hideheader',
                param: {
                    animate: true
                }
            });
        },

        //只更新title，不重置事件，不对header其它地方造成变化，仅仅最简单的header能如此操作
        update: function (title) {
            _.requestHybrid({
                tagname: 'updateheadertitle',
                param: {
                    title: 'aaaaa'
                }
            });
        },

        initialize: function () {
            this.propertys();
        }
    });

});

请求类

虽然 get 类请求可以用 jsonp 方式绕过跨域问题，但是 post 请求是一个拦路虎。为了安全性问题服务器会设置 cors 仅仅针对几个域名，Hybrid 内嵌静态资源可能是通过本地 file 的方式读取，所以 cors 就行不通了。另外一个问题是防止爬虫获取数据，由于 Native 针对网络做了安全性设置（鉴权、防抓包等），所以 H5 的网络请求由 Native 完成。可能有些人说 H5 的网络请求让 Native 走就安全了吗？我可以继续爬取你的 Dom 节点啊。这个是针对反爬虫的手段一。想知道更多的反爬虫策略可以看看我这篇文章 Web反爬虫方案

这个使用场景和 Header 组件一致，前端框架层必须做到对业务透明化，业务事实上不必关心这个网络请求到底是由 Native 还是浏览器发出。

  HybridGet = function (url, param, callback) {

};
HybridPost = function (url, param, callback) {

};

真实的业务场景，会将之封装到数据请求模块，在底层做适配，在H5站点下使用ajax请求，在Native内嵌时使用代理发出，与Native的约定为

  requestHybrid({
  tagname: 'NativeRequest',
  param: {
    url: arg.Api + "SearchInfo/getLawsInfo",
    params: requestparams,
    Hybrid_Request_Method: 0,
    encryption: 1
  },
  callback: function (data) {
    renderUI(data);
  }
});

常用 NativeUI 组件

一般情况 Native 通常会提供常用的 UI，比如加载层loading、消息框toast

  var HybridUI = {};
HybridUI.showLoading();
//=>
requestHybrid({
    tagname: 'showLoading'
});

HybridUI.showToast({
    title: '111',
    //几秒后自动关闭提示框，-1需要点击才会关闭
    hidesec: 3,
    //弹出层关闭时的回调
    callback: function () { }
});
//=>
requestHybrid({
    tagname: 'showToast',
    param: {
        title: '111',
        hidesec: 3,
        callback: function () { }
    }
});

Native UI与前端UI不容易打通，所以在真实业务开发过程中，一般只会使用几个关键的Native UI。

账号系统的设计

Webview 中跑的网页，账号登录与否由是否携带密钥 cookie 决定（不能保证密钥的有效性）。因为 Native 不关注业务实现，所以每次载入都有可能是登录成功跳转回来的结果，所以每次载入都需要关注密钥 cookie 变化，以做到登录态数据的一致性。

使用 Native 代理做请求接口，如果没有登录则 Native 层唤起登录页
直连方式使用 ajax 请求接口，如果没登录则在底层唤起登录页（H5）

  /*
    无论成功与否皆会关闭登录框
    参数包括：
    success 登录成功的回调
     error 登录失败的回调
    url 如果没有设置success，或者success执行后没有返回true，则默认跳往此url
*/
HybridUI.Login = function (opts) {
    //...
};
//=>
requestHybrid({
    tagname: 'login',
    param: {
       success: function () { },
       error: function () { },
       url: '...'
    }
});
//与登录接口一致，参数一致
HybridUI.logout = function () {
    //...
};

在设计 Hybrid 层的时候，接口要做到对于处于 Hybrid 环境中的代码乐意通过接口获取 Native 端存储的用户账号信息；对于处于传统的网页环境，可以通过接口获取线上的账号信息，然后将非敏感的信息存储到 LocalStorage 中，然后每次页面加载从 LocalStorage 读取数据到内存中（比如 Vue.js 框架中的 Vuex，React.js 中的 Redux）

Hybrid 资源管理

Hybrid 的资源需要 增量更新 需要拆分方便，所以一个 Hybrid 资源结构类似于下面的样子

假设有2个业务线：商城、购物车

  WebApp
│- Mall
│- Cart
│  index.html //业务入口html资源，如果不是单页应用会有多个入口
│  │  main.js //业务所有js资源打包
│  │
│  └─static //静态样式资源
│      ├─css 
│      ├─hybrid //存储业务定制化类Native Header图标
│      └─images
├─libs
│      libs.js //框架所有js资源打包
│
└─static
   ├─css
   └─images

增量更新

每次业务开发完毕后都需要在打包分发平台进行部署上线，之后会生成一个版本号。

Channel	Version	md5
Mall	1.0.1	12233000ww
Cart	1.1.2	28211122wt2

当 Native App 启动的时候会从服务端请求一个接口，接口的返回一个 json 串，内容是 App 所包含的各个 H5 业务线的版本号和 md5 信息。

拿到 json 后和 App 本地保存的版本信息作比较，发现变动了则去请求相应的接口，接口返回 md5 对应的文件。Native 拿到后完成解压替换。

全部替换完毕后将这次接口请求到的资源版本号信息保存替换到 Native 本地。

因为是每个资源有版本号，所以如果线上的某个版本存在问题，那么可以根据相应的稳定的版本号回滚到稳定的版本。

一些零散的解决方案

静态直出

“直出”这个概念对前端同学来说，并不陌生。为了优化首屏体验，大部分主流的页面都会在服务器端拉取首屏数据后通过 NodeJs 进行渲染，然后生成一个包含了首屏数据的 Html 文件，这样子展示首屏的时候，就可以解决内容转菊花的问题了。
当然这种页面“直出”的方式也会带来一个问题，服务器需要拉取首屏数据，意味着服务端处理耗时增加。
不过因为现在 Html 都会发布到 CDN 上，WebView 直接从 CDN 上面获取，这块耗时没有对用户造成影响。
手 Q 里面有一套自动化的构建系统 Vnues，当产品经理修改数据发布后，可以一键启动构建任务，Vnues 系统就会自动同步最新的代码和数据，然后生成新的含首屏 Html，并发布到 CDN 上面去。

我们可以做一个类似的事情，自动同步最新的代码和数据，然后生成新的含首屏 Html，并发布到 CDN 上面去

离线预推

页面发布到 CDN 上面去后，那么 WebView 需要发起网络请求去拉取。当用户在弱网络或者网速比较差的环境下，这个加载时间会很长。于是我们通过离线预推的方式，把页面的资源提前拉取到本地，当用户加载资源的时候，相当于从本地加载，即使没有网络，也能展示首屏页面。这个也就是大家熟悉的离线包。
手 Q 使用 7Z 生成离线包, 同时离线包服务器将新的离线包跟业务对应的历史离线包进行 BsDiff 做二进制差分，生成增量包，进一步降低下载离线包时的带宽成本，下载所消耗的流量从一个完整的离线包（253KB）降低为一个增量包（3KB）。

https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=2247488218&idx=1&sn=21afe07eb642162111ee210e4a040db2&chksm=f951a799ce262e8f6c1f5bb85e84c2db49ae4ca0acb6df40d9c172fc0baaba58937cf9f0afe4&scene=27#wechat_redirect

拦截加载

事实上，在高度定制的 wap 页面场景下，我们对于 webview 中可能出现的页面类型会进行严格控制。可以通过内容的控制，避免 wap 页中出现外部页面的跳转，也可以通过 webview 的对应代理方法，禁掉我们不希望出现的跳转类型，或者同时使用，双重保护来确保当前 webview 容器中只会出现我们定制过的内容。既然 wap 页的类型是有限的，自然想到，同类型页面大都由前端采用模板生成，页面所使用的 html、css、js 的资源很可能是同一份，或者是有限的几份，把它们直接随客户端打包在本地也就变得可行。加载对应的 url 时，直接 load 本地的资源。
对于 webview 中的网络请求，其实也可以交由客户端接管，比如在你所采用的 Hybrid 框架中，为前端注册一个发起网络请求的接口。wap 页中的所有网络请求，都通过这个接口来发送。这样客户端可以做的事情就非常多了，举个例子，NSURLProtocol 无法拦截 WKWebview 发起的网络请求，采用 Hybrid 方式交由客户端来发送，便可以实现对应的拦截。
基于上面的方案，我们的 wap 页的完整展示流程是这样：客户端在 webview 中加载某个 url，判断符合规则，load 本地的模板 html，该页面的内部实现是通过客户端提供的网络请求接口，发起获取具体页面内容的网络请求，获得填充的数据从而完成展示。

NSURLProtocol能够让你去重新定义苹果的URL加载系统(URL Loading System)的行为，URL Loading System里有许多类用于处理URL请求，比如NSURL，NSURLRequest，NSURLConnection和NSURLSession等。当URL Loading System使用NSURLRequest去获取资源的时候，它会创建一个NSURLProtocol子类的实例，你不应该直接实例化一个NSURLProtocol，NSURLProtocol看起来像是一个协议，但其实这是一个类，而且必须使用该类的子类，并且需要被注册。

WKWebView 网络请求拦截
方法一（Native 侧）：
原生 WKWebView 在独立于 app 进程之外的进程中执行网络请求，请求数据不经过主进程，因此在 WKWebView 上直接使用 NSURLProtocol 是无法拦截请求的。

但是由于 mPaas 的离线包机制强依赖网络拦截，所以基于此，mPaaS 利用了 WKWebview 的隐藏 api，去注册拦截网络请求去满足离线包的业务场景需求，参考代码如下：

  [WKBrowsingContextController registerSchemeForCustomProtocol:@"https"]

但是因为出于性能的原因，WKWebView 的网络请求在给主进程传递数据的时候会把请求的 body 去掉，导致拦截后请求的 body 参数丢失。

在离线包场景，由于页面的资源不需要 body 数据，所以离线包可以正常使用不受影响。但是在 H5 页面内的其他 post 请求会丢失 data 参数。

为了解决 post 参数丢失的问题，mPaas 通过在 js 注入代码，hook 了 js 上下文里的 XMLHTTPRequest 对象解决。

通过在 JS 层把方法内容组装好，然后通过 WKWebView 的 messageHandler 机制把内容传到主进程，把对应 HTTPBody 然后存起来，随后通知 JS 端继续这个请求，网络请求到主进程后，在将 post 请求对应的 HttpBody 添加上，这样就完成了一次 post 请求的处理。整体流程可以参考如下：

通过上面的机制，既满足了离线包的资源拦截诉求，也解决了 post 请求 body 丢失的问题。但是在一些场景还是存在一些问题，需要开发者进行适配。

方法二（JS 侧）：
通过 AJAX 请求的 hook 方式，将网络请求的信息代理到客户端本地。能拿到 WKWebView 里面的 post 请求信息，剩下的就不是问题啦。
AJAX hook 的实现可以看这个 Repo.

设计师要理解的10个心理学原理

Tue, 20 Apr 2021 17:18:05 CST

前言：高手的设计作品都是有理有据的，学习设计心理学，除了让作品有依据，在向客户提案时也会更有说服力。而作为设计师除了要掌握基本的设计规范外，还需要对每个层面的情感以及创造情感的心理学原理有更深入的了解。好的设计不仅能解决问题，还能为用户带来积极的情感，并通过三个层面产生情感：本能层：用户想要的感受；行为层：用户想要做什么；反思层：用户想要成为谁。

1.格式塔原则

相似原则 人的眼睛会把具有相似特征的元素当成一个整体，认为这些元素具有相同的作用。 ▲ 界面中的绿色图标具有相同的功能，方便用户快速认知和操作。因此在设计具有相同功能或内容的界面元素时，应该保持一致性。 应用位置：导航、链接、按钮、内容页。 连续原则 用户倾向于把连续排列的元素视为一个整体。这条原则与对称性和相似性密切相关。通过在序列上创建相似且重复的元素，引导用户的视线方向，使操作更加连贯和清晰。 ▲ 只露出一部分的卡片会向用户发出信号，表示滑动可以查看更多的书。 应用位置：菜单和子菜单、列表、产品页、轮播页。 封闭原则 当看到不完整的图像时，我们会依据已有的经验把不完全封闭的图像当成一个统一的整体，这是在平面或logo设计中常用到的原则。 ▲ 尽管页面右上方的饼图只显示了一部分，我们仍然能够轻松地识别出来。 应用位置：图标、加载、数据可视化。 邻近原则 人们会将彼此相邻的元素视为一组。在设计时要注意使用间距将元素组合在一起。使用较大的间距来分隔大的内容组，再使用较小的间距来分隔大内容组中的小内容组。 ▲ 页面上的每个卡片中都含有4组信息，很难快速识别具体的内容。通过调整间距，可以将这些信息清楚地分为2组。 应用位置：导航、卡片、横幅、列表页、分页。 对称原则 我们喜欢看到对称且平衡的事物。它是所设计领域中最常用和最安全的原则，有助于营造一种稳定感和秩序感。 ▲ 对称的布局不仅增强了用户的印象，还强调了中间的视频播放按钮。 应用位置：产品展示页、列表、导航以及任何内容丰富的页面。 共同区域原则 通过信息分组和内容组织，实现内容的组合，有助于提升内容的层次结构和可扫描性。 ▲ 卡片式UI有助于将信息分组并创建内容的层级深度。 应用位置：卡片、内容、服务、摘要。 共同命运原则 向同一方向移动的元素被认为比静止或向另一个方向上移动的元素更相关。这个原则有利于建立不同分组或状态之间的关系。 ▲ 页面右侧的3个图形方向相同，有利于展示信息并让用户了解它们的功能。 应用位置：导航/下拉、折叠条目、工具提示、产品滑块、滚动条。

2.焦点

看东西时，我们的视线往往会首先关注最突出的元素。理解这种行为有助于我们在设计中创建一个“锚点”，从而引导用户按照我们设计的场景查看内容。 ▲ 通过人物插画将用户的注意力引导到账单和人数等主要信息上。 应用位置：内容、登录页、产品页。

3.冯·雷斯托夫效应

又称隔离效应，相对于普通事件或物体，独特、有特色的事件或物体更容易被人记住。应用此原则的元素通常独立存在，不需要向用户导航额外的信息。 ▲ 中间的升级插画部分在整个页面上是独立存在的，并且吸引注意力是号召性用语或转化的关键。 应用位置：价格表、促销页、图标入口。

4.本能反应

根据现实中的用户行为创建视觉上引人入胜的体验。例如看幽默类视频的时候，如果在视频的高潮伴有笑声音效，我们也会更容易跟着笑起来。如果能让用户感觉良好和舒适，他们也会更喜欢我们的设计。 应用位置：产品图、插图、摄影。

5.色彩心理学

许多研究表明，颜色对我们的潜意识有特殊的影响。性别、宗教和文化对颜色的理解也有所不同。 ▲ 关于颜色的运用，这张色彩心理学海报介绍了丰富的方法。同时也要记住最广泛使用的系统颜色：红色代表错误；绿色代表成功；蓝色代表进行中；黄色代表警告。

6.形状心理学

▲ 同颜色一样，人们的潜意识对不同的形状也有不同的反应： 圆形、椭圆形：传达积极的信息，通常与社区或关系有关； 正方形、三角形：传达强烈的信息，通常与强度和稳定性有关； 垂直线：表示强度或力量。 水平线：表示平静、相等或安静。

7.双重编码理论

这个理论解释了人类需要视觉和语言信息来尽快处理信息。为了最大限度地提高设计的有效性，不应该删除必要的说明性文字。 ▲ 大多数App的底部导航栏都利用图标与文字相结合的方式让用户快速知道功能。另一个好的设计案例：

8.并行设计

人眼倾向于看到平行因素比其他因素更相关。这一原理经常用来对同一页面中的两组不同内容进行分类。 ▲ 使用垂直排列的卡片代表相同的问题，水平排列的卡片代表不同的问题。

9.公共区域

这一原理类似于格式塔原则中的相似原则。公共区域通过使用线、形状或颜色划分的方式创建。 ▲ 如果页面需要用户不断滚动来查看内容，可以考虑使用颜色来更清楚地划分这些内容，而不仅仅是使用间距。

10.扫描模式

根据NNGroup、UXPin等设计团体的研究，最常用的两种扫描模式是“F型”和“Z型”： “F型”应用最为广泛，尤其是对于内容丰富的网站。 “Z型”用于那些文字信息少，最后需要强调用户点击类的网站。了解如何使用这些模式后，我们就可以有效地选择布局和安排元素来实现设计目标。最后第一印象是最令人难忘的，好的体验可以在用户与产品之间建立持久的联系。原文：blog.prototypr.io/10-psychological-rules-i-used-to-make-users-love-at-first-sight-55c71f99bfa 作者：Hoang Nguyen 译者：Clippp 来源：Clip设计夹 (ID:ClipppDesign)

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

交互设计师怎样做竞品分析？

Mon, 08 Mar 2021 08:00:21 CST

前言：做竞品分析包含了太多方面，本文主要是针对交互设计师如何做竞品分析进行分享。

什么是竞品分析？

竞品分析的对象一般是和自家产品存在直接/间接竞争，或者用户人群、产品定位和功能存在重叠的产品。作为交互设计师，我们研究竞品分析时需要从产品概况、功能、流程和交互等方面全方位的分析。并从竞品中得到对应的启发，将其复用到我们自家的产品中，这也是竞品分析的意义所在。

为什么要做竞品分析？

做竞品分析可以快速了解行业头部产品的设计情况，我们选取竞品分析的对象一般都是同行业主流的产品，这些产品对目标用户的认知和使用习惯已经培养起来了，这时候我们分析竞品，可以减少我们设计失误的风险。正所谓知己知彼百战不殆。做竞品分析有助于产品经理和设计师更好的跟进和学习。目前网上的大部分竞品分析主要都做的大而空，好多都是偏行业分析，对于交互设计师而言，看完之后无法得到有用的信息。同时对于交互设计而言，帮助意义不大。

如何做适合交互设计师的竞品分析？

做适合交互设计师的竞品分析，那么主要站在交互的角度来做竞品分析。首先需要弄清竞品的基本情况，例如产品的定义、产品的主要使用场景和产品的目标人群等，这些大前提了解后，那么对于之后的分析才能保证有全局感，避免因为不了解竞品的定位和目标人群导致分析错误。其次是分析竞品的主要功能和主流程操作有哪些，这些是竞品的核心部分。分析竞品的哪些功能和流程做的好，这些流程和功能是否也符合自家产品的定位和目标人群。能否从这些竞品功能和流程中得到启示。然后就是竞品的使用体验，使用体验的好坏，直接与产品的留存率挂钩，用户的使用体验越好，则产品的留存率越高，产品的用户增长会越快。最后就是交互体验，分析竞品在交互方面的优缺点，通过痛点找到其机会点，并运用到自身产品上。

竞品分析内容包含哪些？

竞品分析可以包含四大部分。第一部分讲解竞品概况。第二部分讲解功能与流程。第三部分讲解用户的使用体验。第四部分讲解交互体验。

1.竞品概况

做竞品分析之前，找准目标竞品，然后对目标竞品进行详细分析，避免因为自家的产品和竞品存在明显的产品定义和使用人群等差异而盲目的借鉴，这样“借鉴”的设计反而对我们自家的产品设计有害。竞品的概况可以从四个方面着手，他们分别为产品定义、使用场景、目标用户和特征集合。通过了解这四种情况，可以很好全局观的了解竞品概况。产品定义：了解竞品的产品定义，通过产品的定义可知道竞品的定位。产品的形态是基于产品定位而形成，所以产品定义很重要，它是产品根本。使用场景：分析竞品的主要使用场景有哪些，通过分析竞品的使用场景，看看和我们的使用场景是否存在差异，了解竞品的使用场景，可方便后续我们分析他们的交互设计。目标用户：竞品的目标用户是哪些，了解竞品的目标用户，那么我们分析他们的功能、流程和使用交互的动机可以更好的得到解释。特征标签：竞品的标签化的特征，通过标签化可以快速了解竞品的特征。

2.功能与流程

竞品的功能与流程这是偏产品设计层面的，一个优秀的交互设计师，是完全可以左右产品功能决策。所以掌握竞品和自家产品的功能与流程，对于做交互设计师来说具有重要的意义。产品功能：竞品的功能主要有哪些，功能是否和产品的定义、使用场景和目标用户产品相匹配。操作流程：竞品的操作流程主要有哪些？找出竞品的核心功能和对应的操作主流程。分析竞品的主流程在操作流程是否高效、顺畅。

3.使用体验

这里的使用体验是指用户在使用过程中的整体感受。使用体验包含用户操作过程中的效率，对信息的呈现和布局的理解。是否存在干扰信息导致用户认知和操作出错，使用起来是否存在压力的情况等。操作效率：用户在操作过程中的整体效率度，整体操作流程越简洁，则操作效率度越高。用户满意度也越高。信息布局：产品的信息以何种设计形式展示出来，展示的整体布局是否统一而清晰。信息呈现：信息以何种方式呈现，统一而层级分明的呈现方式可以极大的提升用户获取信息的效率。信息干扰：用户通过展示出来的界面来获取信息和操作，以满足用户的需求，所以设计师做设计本质上是对信息的设计，信息设计的不好，就会出现信息干扰的情况，针对这种情况，如何减少信息干扰是设计师需要时刻思考。使用压力：用户在使用产品的过程中都会存在使用压力的情况。产品的体验越好，则用户使用起来的压力就越小，所以设计师在设计产品的过程中要尽量减少用户的使用压力。使用成本：用户在使用产品的成本情况，使用成本越高，用户越容易流失，产品的留存率也就越低，留存率是产品是否实现快速增长的一个重要指标，所以我们要尽量减少用户的使用成本。

4.交互体验

主要体验产品的交互层面使用情况。交互体验主要和六个方面有关，他们分别是流畅度、反馈、防止错误、一致性、可见性和组件使用。流畅度：用户在操作流程过程中越顺畅，则流畅度越高，流畅度一般和操作路径、用户对界面的认知有关，认知负担越小，操作路径越简洁，则流畅度越高。反馈：产品的反馈直观的表现为界面的变化（少数为声音和震动），通过这种变化，用户能够更加友好高效地与产品进行交互，更加专心地投入到任务流程当中去。及时的反馈响应以确保用户知道自己所处的状态，否则会让用户觉得反应迟钝；另一方面，我们也要避免过度的信息反馈，而尤其注意不要反馈错误信息，错误的信息对用户造成的影响是巨大的。当用户执行完一步操作后，系统没有及时甚至没有给出相应的反馈提示，就会给用户带来疑惑（实现模型与心理模型冲突），让用户不能确定自己的操作是否被执行、执行是否成功、执行整体进度、或者是执行后会产生怎么样的影响、能在哪里查询到结果以及执行后是否可以被撤销等等。而这其中的任何一个环节都有可能影响到用户对当前任务的理解以是否执行下一步操作，从而影响到产品的用户体验。防止错误：设置防错的机制，减少用户犯错。对于用户已犯错提供挽回措施。好的产品都会防止用户犯错，在用户犯错前给予友好提示，挽回犯错。一致性：遵循统一的产品设计规范／逻辑。这里的一致性包含产品和跨平台产品之间的一致性。产品间的一致性，包含视觉和交互的一致性，无论是文案、视觉风格、组件样式等都包含一致性。可见性：对于重要信息，让用户可以清楚的找到，并发现，在用户需要的时候可快速的进行操作/查看。组件使用：产品设计的好坏，组件的使用是重要的参考标准，组件使用的准确统一则交互体验也就越好，所以交互设计师要多分析优秀产品的组件使用。作者 | Echo 来源 | Echo的设计笔记(id:uxecho)

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

设计师应该如何正确的做竞品分析？

Mon, 08 Mar 2021 10:43:22 CST

导语：在我们的设计工作中，竞品分析是很重要的。通过竞品分析可以帮助我们了解与验证我们的设计，为我们带来设计灵感与设计思考，辅助我们产出更好的设计策略与设计方案。但是，竞品分析如果做的不正确，浪费时间的同时对于设计也不会有什么帮助。那么，设计师应该如何正确的做竞品分析呢？

在平时的工作中，有拿不准的设计形式时我会请教我的导师，她经常会告诉我行业内的top级产品是怎么做的？也常让我也去多看一下、多分析别人是怎么做的？这样自己拿不准的地方也就知道如何修改了。

其实这就是一个做竞品分析的过程，对于初阶的设计师来说，做竞品分析特别重要，所以自己也很注重这方面的学习与练习。竞品分析得越多，我们的脑海里沉淀的设计方式也就越多，我们就能更容易的回答为什么要这样设计？哪一种设计形式会更好？

学习与总结了关于设计师做竞品分析的一些方法，分享给大家，希望对大家有所帮助，也欢迎大家多多指教呀～

文章大纲：

明确目标，选择竞品
了解竞品商业背景
基于目的，分析竞品
视觉分析
产出竞品分析报告

一、明确目标，选择竞品

1. 明确目标

在竞品分析之前，我们要根据我们要解决的问题，明确我们此次竞品分析的目的是什么？我们想要在竞品分析过程中获得怎样的收获？

根据我们的目标，进行竞品选择。若没有明确目标我们很容易在分析过程中走偏，分析很多不相干的内容，容易迷失方向，获取不到实质性的帮助。

比如我们的目的是想了解feed流设计形式，那么我们在后续竞品分析过程中就应该重点关注feed流的布局形式有哪些，feed流中卡片中图文关系是怎样的？图片有几种比例等？

我们的竞品可以选择社交类产品，比如Facebook、微博、ins这种feed流应用得特别多的top级产品。比如是想进行视觉风格改版设计，那么在竞品分析时我们应该多关注竞品的视觉风格，图标应用了哪种风格类型？体现了哪种设计趋势等等。

2. 选择竞品

竞品一般分为直接竞品与间接竞品。

直接竞品：同类型直接竞争关系的产品，比如淘宝与京东；
间接竞品：使用场景和用户群体比较接近的产品，比如淘宝与得物这类垂直领域的产品。

我们在做竞品分析时，直接竞品建议选择业内TOP级产品进行分析，间接产品建议选择垂直领域的独角兽产品进行分析。

因为TOP级的产品已经非常成熟，他们已经养成了用户的使用习惯，塑造了用户的心智，分析TOP级的产品，我们就相当于站在巨人的肩膀上，更易获取有用的信息。

用到的工具：

1）百度指数

通过百度指数，我们可以找到国内不同行业产品的排行榜与产品热度，进而选择我们的竞品。

http://zhishu.baidu.com/v2/index.html#/

2）易观千帆指数

可以查到不同行业产品月度排行榜和产品基本信息。

https://qianfan.analysys.cn/refine/view/rankApp/rankApp.html

3）七麦数据

国内专业的移动应用数据分析平台，覆盖AppStore&GooglePlay双平台，提供iOS&Android应用市场多维度数据分析，推荐使用。

https://www.qimai.cn/

二、了解竞品商业背景

选择竞品后，我们需要简单的了解竞品的商业背景，了解产品的定位、用户群体、日活、月活、经营背景、服务理念等等，对竞品有更深入的了解。

我们可以通过去产品官网了解这些信息，也可以通过百度百科、维基百科去查询竞品的商业背景。推荐使用维基百科。

了解竞品的商业背景后，我们需要简单的做一个表格或者文档，记录我们所获取到信息，便于后续自己以及其他同事查看与了解竞品的商业背景。

三、基于目的，分析竞品

做竞品分析其实是基于用户体验的5要素（战略层、范围层、结构层、框架层、视觉层）去分析的，作为设计师我们重点关注框架层与视觉层。我们要时刻围绕我们的目的进行竞品分析，并且要记录与保存好我们的分析过程。

很多设计师做竞品分析就是拿出手机去体验这个产品，体验完了就完了，什么产出物都没有这是不行的。

我们要时刻有这样一个概念，我们做的所有分析都是辅助我们最后的设计方案产出的，这些前期的分析都应该整理成文档帮助我们或者同事作为资料参考，同时也可以沉淀为组内的设计资料。

1. 拆解用户路径

在竞品分析阶段，我们首先需要了解竞品的框架层，拆解用户路径，并截图保存每个路径所涉及的页面设计，并制作页面路径截图包。

对于整个竞品框架层的分析，其实也很简单，就是将我们自己作为用户，把所有主流程跑一遍，每个路径所涉及的页面都截图保存，再在文档里进行路径梳理。

我以同程为例，进行机票查询路径流程分析，最后整理产出的页面路径截图包如下：

同样的，如果我们想知道feed流图片的排列形式是怎样的？那我们就通过分析feed流应用得广与多的产品，分析他们的图片布局框架是怎样的？这一阶段就是多看、多存、多分析。

2. 保留页面截图

当然我们是结合我们需要解决的问题与目标进行竞品分析的，如果我们只需分析视觉形式，那我们就仅仅只截图不同产品该模块的设计形式截图即可，不需要分析所有的路径。

比如我们此次做竞品分析的目的是了解“我的”页面背景墙的设计，那我们就只需要截图不同产品背景墙的设计形式即可。

我们一定要将截图根据路径或者按照我们自己的总结分类进行整理，方便后续自己与同事的查看，将路径截图包作为资源管理，也方便后续截图的更新与二次分析。

四、视觉分析

这一步是我们需要重点分析的阶段，同样也需要产出视觉分析文档，文档越详细对我们后面的设计帮助越大。我们从“形色字构质”五个维度对竞品进行视觉分析，并产出视觉分析文档，作为我们后续的设计参考。

视觉分析文档主要包括基础规范、设计组件、设计亮点三个部分。

1. 基础规范

基础规范就是界面最基础、最通用的元素的设计规范。

1）栅格系统

分析竞品的栅格系统，分析最小原子单位为多少，了解其布局结构。

2）色彩

竞品的品牌色、辅助色、背景色与中性色等、以及这些颜色的使用场景。

3）文字

不同场景的文字大小与文字层级关系。

2. 设计组件

设计组件的梳理要结合我们项目的实际情况进行分析，除了通用组件外，还应该有特别的组件。

比如我们是做社交产品的，我们的产品中涉及很多社交动态的卡片形式，那么我们就可以把这部分做成组件形式，这些组件都能很好的帮助我们后续去搭建页面，快速出效果图。

1）通用组件

按钮：按钮的设计形式与使用场景

列表：列表的多种表现形式

弹窗：不同的弹窗样式与使用场景

缺省页：缺省页的设计形式与布局样式

2）特色组件

特色组件应该是我们基于自身产品属性建立的最常用的业务属性组件。

feed流卡片：图片、文字结合形式，以及不同图片数量时的展现方式。

在整理竞品设计组件时，我们并不一定要全部做成可编辑的组件，在时间紧的情况下，截图设计组件也是可以的，只要能帮助到我们后续做设计都是可以的。

3）设计亮点

设计亮点是我们在进行竞品分析时，觉得竞品中哪些设计点是做得很好的？是值得我们借鉴的地方，可以记录下来。后续在自身产品设计中我们可以很好的明白哪些模块是我们的设计发力点。

五、竞品分析报告产品

做了前面所有的分析后，我们需要产出竞品分析报告，作为资料参考，为自己或者同事提供设计参考，带来设计灵感，提高设计效率，这就是竞品分析最大的价值。

竞品分析最后的产出物为一下四部分：

商业背景文档
路径/模块截图包与分析说明
竞品视觉规范
设计亮点

六、总结

以上就是今天所分享的关于设计师做竞品分析的方法，总结起来为以下5点：

明确目标，选择竞品
了解竞品商业背景
基于目的，分析竞品
视觉分析（路径拆解、制作页面截图包）
产出竞品分析报告（基础规范、设计组件、设计亮点）

前期我们分析得越多越详细对我们后续的帮助越大。做竞品分析一定要产出最后的分析文档，作为自己或组内后续设计的参考资料，为大家的设计带来灵感与帮助。

本文由 @小鱼晴子原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

常被混淆的账号体系与账户体系

Sat, 09 Jan 2021 18:59:17 CST

导语：账户体系是任意一款互联网产品都必有的基础体系，而账户体系的产品设计文章却寥寥无几。本文小编将从互联保险产品的账户体系入手，来聊一聊如何基于复杂业务场景构建一套完整账户体系。

账户体系、账号体系、用户体系的区别与联系

在分享如何构建账户体系之前，先聊一聊小编对 「账户」「账号」「用户」三者之间关联和区别的理解。

账户可以定义是一个具有特定信息含义的内容集。比如一张身份证，一本银行存折，一份个人信用资料等。
账号则是一组特定符号组成的序列，且与账户有一一映射关系。比如身份证号，银行卡号，个人征信代码等。
用户则是通过这组特定字符序列与内容集产生关联的个体，同时也是账户内容所描述的特定个体。

在互联网产品中， 用户体系往往是面向用户，更偏重于用户运营与增长。而 账户体系则是面向业务，更偏重于产品结构与业务支撑。 账号体系则是桥接在用户体系与账户体系之间，为用户体系提供价值体现的同时，又可为账户体系提供服务的支持。换言之，在偏重用户体验的产品中，账户体系的价值常常被忽略。而在偏重于业务效率与供需交易的产品中，账户体系的价值举足轻重。

案例：信用卡

这里小编通过「信用卡」这个大家生活中都会接触的产品来讲讲上述三者的区别和关联。

对于一张信用卡来讲，我们站在普通人的角度看，它的用户自然是使用它的人。它的账号自然是登录或支付的账号和密码。而它的账户可能就是它的消费记录，可用金额等。读到这里大家可能觉得这个例子非常的简单。

那么我们换一个思考的角度，站在产品经理的立场看，对于一个信用卡产品来讲，它的用户体系，账号体系，账户体系又分别是什么呢？

在小编看：

信用卡的 用户体系就是它的用户成长体系，可能是用户积分体系，会员等级体系等这些可以提升用户粘性，促进用户刷卡消费，提升业务量的产品运营模块。而这部分模块往往是直接面向用户的，我们可以在各种信用卡产品中轻易找到。
信用卡的 账号体系就是信用卡的使用通道或者说产品触达用户的渠道。可以是线下直接刷卡消费，这时使用的账号就是卡号和支付密码。也可以线上产品端扫码消费，或者第三方支付通道调起，这时必然要通过产品端的登录账号和密码以及付款账号和密码等。这些不同的用途的账号和密码共同组建了一个复杂的账号体系。
账户体系就更加复杂了，包括普通用户可以看到的个人基本信息，个人认证信息，信贷账户，分期账户，分期账户，余额账户，借贷账户，消费记录，贷款记录，还款记录等。以及普通用户看不到的银行信用评级记录，逾期记录，卡片升级记录，异常消费记录等等。由此也可以看出账户体系更多是面向业务的，根据业务不同，账户体系的设计偏重也不同。

那么下面小编将通过互联网保险产品的账户体系 搭建方法论来聊一聊如何设计一个可以应对复杂业务场景的账户体系。

搭建账户体系的第一步：用户是谁，具有什么样的特点？

在互联网保险行业中，由于其业务场景的多元化，可以分为持牌保险企业，保险经纪公司，理赔服务供应商，代理人展业供应商等多种产品形态。小编将通过复杂度适中的互保经纪公司的产品为例来进行分析。

用户关系定位：

首先将保险产品的需求侧用户分为以下四类：

个人用户：进行投保和被保险的个人。
个人客户：存在的被保险的个人。
企业用户：进行投保和被保险的企业。
企业客户：进行被保险的企业。

这里的用户和客户的区别在于： 用户是与产品产生直接行为的个体，而客户是与产品产生间接行为的个体。间接行为就是该个体并未与本产品中产生直接交互行为，而是通过第三方代为完成的。比如企业为员工提供的补充医疗险，就是企业为员工集体购买的险种。当产品本身为被保险人提供保全或理赔服务时，则需要为该被保险人进行账户的创建和维护。客户与用户的具体关联逻辑将在第二步中进行讲解。

案例：个人账户体系

当确定了用户是谁后，在搭建账户体系时就要为用户添加标签，创建账户规则及字段，以及不同类型的账户的下的属性字段有哪些。企业用户因涉及到供给侧，需求侧以及第三方服务角色，相对较为复杂，在此就不展开讨论了。此处小编以个人用户为例简单说明一下。

个人用户的账户信息大概可以分为以上七个信息模块。其中基本信息和身份认证信息这两个模块的用途是确定用户的真实性和唯一性。保险行业相对于其他行业，在进行投保核保时是需要进行个人身份的认证。因而保险产品更容易获取用户的真实信息，用于保险风控及用户运营。

这里可能有读者朋友会问： 为什么将基本信息和身份认证信息归并在个人账户体系中，而不是放在用户体系或者账号体系中。

这里小编解释一下自己的考虑。首先没有归并到用户体系的原因很简单，用户体系的作用是为了促进用户与产品的粘性，进而促进业务增长。而个人基本信息和身份认证信息的归并并不能起到这方面的作用。而在较为复杂或繁琐的产品中，可能会存在多账号的情况，此时如果将基本信息和认证信息放入账号体系中，可能会带来数据不同步或数据冗余的问题。

保险信息和所属企业的用途是确定个人是用户还是客户以及该个人与保单之间的关联关系。因为一个人可以关联多张保单。

如该个人在某一保单中是连带被保险人，那么该人对于该保单/该保险产品而言就是客户，因为Ta无法与产品发生直接交互行为，而是需要主保险人代为进行保全或理赔的行为交互。
如该个人在某一保单中是主被保险人，但该保单的理赔收单方式是以企业为单位收单理赔。那么该个人对于该保单/该保险产品而言仍是客户，因为TA没有与产品发生直接交互行为。
如该个人在某一保单中是主被保险人，且他可以直接在产品中提起保全或理赔的申请，那么该个人对于该保单/该保险产品是用户。

支付信息的用途是在用户与产品产生理赔行为时所需要处理的业务信息模块。这其中较为重要的是额度账户模块，将在第二步重点说明。而登录账号模块作为各种产品的基础支撑模块，将在第三步中重点讨论一下。运营信息模块属于用户体系部分，本文不做扩展。

搭建账户体系的第二步：业务是什么，具有什么样的区别？

如果第一步是确定账户的标准化属性，那么这一步则是确定账户的业务化属性。因为小编讨论的是保险产品的账户体系，那么该账户体系主要围绕的就是险种责任和险种额度。即交易业务的规则和金额。

投保方案中的每条险种责任对应的险种额度都是不同的，被保险人的理赔诉求与险种责任是一一对应的。

在互联网保险中，业务主要可以分为两个思考方向：

提供什么服务？比如投保，保全，理赔。
支持什么险种？比如健康险，财险，车险，寿险等。

这里我们就通过支持 补充医疗险的保全和理赔的团体保单业务为例子来简单分析一下。

补充医疗保险是相对于基本医疗保险而言的，包括企业补充医疗保险、商业医疗保险、社会互助和社区医疗保险等多种形式，是基本医疗保险的有力补充，也是多层次医疗保障体系的重要组成部分。

从业务种类来进行保险账户体系的分析与构建：

保险的业务种类可以直接理解为保险的险种区分及具体理赔或保全规则。因为讨论的是补充医疗保险的保全和理赔业务，所以第一个属性就是账户业务类型，基本医疗保险或补充医疗保险。第二个重要的属性则是保险项目性质，这类企业的补充医疗保险项目会分为风险型和基金型。

所谓风险型保险项目是以一个特定时间段为标准（大多是一年一期），到期续保后重置保险额度，不进行保额累加的操作。而基金型保险项目则可以在到期续保后进行险种额度的累加。因而需要在账户中区分保单性质是基金型还是风险型。

还有一类重要的维度就是保险期间，也就是险种额度有效期。例如去年的理赔申请仅能使用去年的险种额度而不能使用今年的险种额度。当然还有很多其他的规则，比如共享额度，即多个险种共用一个额度。企业公共额度，即在某些特殊病中对个人补充医疗账户的额外的额度补充。

根据上述描述，我可以将额度账户切分为四层结构，即项目层，保单层，责任层，额度层。额度有效期则是从保单层到责任层再到额度层皆有关联。

从业务流程来进行保险账户体系的分析与构建：

保险的业务流程在这里可以理解为理赔流程和保全流程，当被保险人申请理赔服务后，在完成的收单，录单，理算及复核后，会相应的扣除被保险人的对应的险种额度。这其中就会涉及到账户额度的变动。

根据业务流程不同，会延伸出额度加费流程，额度冻结流程，账务清结算流程等。因此在额度层就需要记录该账户的总额度，可用额度，冻结额度，剩余可用额度，初始额度，累计使用额度，累计加费额度。因而就能得到如下图所示的额度账户的结构样例。

搭建账户体系的第三步：账号有哪些，会遇到什么问题？

读到这里，可能会有读者有疑惑，开篇时小编不是将账号体系和账户体系分开来了吗， 为什么账户体系中要考虑账号呢？因为账户体系是一个内容集，我们需要一把钥匙去打开这个内容集，而账号就是触达账户体系的钥匙。但是这把钥匙如何设计也是需要考量的。

有些读者可能在设计账户体系或者初期构建一个C端产品时，会优先搭建账号体系，再根据业务发展逐步的完善账户体系和用户体系。

这种产品设计思路在某些流量为王，偏重用户体验的C端产品中是一种还不错的产品设计思路。但是在一些具有复杂业务场景的行业或产品中可能并不是一个好的设计思路，比如互联网金融，互联网保险或者偏重供需交易业务的互联网+传统行业。为什么这样讲呢？且看小编一一为你解答。

1. 互联网产品的账号类型和适应场景

首先我们先来看看产品账号共有哪些类型，每一种类型的前世今生是怎么样的。

（1）自定义账号类型：

自定义账号起源于PC时代，用户可以根据喜好设定一组字符为账号，没有特定的组合格式。其缺点除了显而易见的因无特定生成规则而不容易记忆外，还无法关联到某一可以认证号主身份的识别信息，丢失后不易直接找回。

（2）邮箱账号类型：

与自定义账号一样起源于PC时代，在自定义账号兴起之后，为了解决其易忘，难维护，难找回的问题。同时使用邮箱也逐步进入中国网民生活中。各大厂开始纷纷使用邮箱作为PC端最常见的登录账号形态。其优点较自定义账号除了降低了维护成本，提高了用户找回账号的便捷性外。也为对流失用户的召回和激活，账号安全性，产品业务推广的提升都起到的至关重要的作用。

（3）手机号码账号类型：

当移动时代的到来后，由于中国大多数网民的手机号普及度远高于邮箱普及度，且国内网民的并未养成如国外网民一样的邮件使用习惯。手机号码作为账号载体受到了绝大多数移动产品的认可。其较邮箱有更高效便民的登录方式，仅需通过验证码即可登录，不需在消耗脑力成本记录密码。尤其当三大运营商对全网手机号实现身份认证后，其对账号安全性的提高是邮箱账号所无法比拟的。现在更有本机手机号一键登录的功能，更极大提高用户体验。

（4）三方授权账号类型：

随着几大国民现象级的APP产品出现，其为抢占各垂直赛道和树立用户心智，衍生出第三方授权登录的概念。仅需要移动产品开启第三方登录接口，用户注册/登录时授权第三方，即可通过第三方账号登录产品。其优点使用户可以跳过较为繁琐的手机号注册登录流程，一键式完成注册/登录，并可将基本信息直接带入产品中。其缺点也十分明显，用户是方便了，但是作为产品本身，无法获得用户真实有效的身份信息。无法对用户进行安全验证，用户召回激活，用户常规运营等行为。

（5）特定账号类型：

最后这一种可能在普通产品中并不常见，但是在某些B端产品或与个人敏感信息相关的产品中颇为常见，比如银行类产品的账号为身份证号，银行卡号。或者社保产品，某些教学平台，OA系统等办公软件。该类账号大多并非主动注册创建的，而是通过被动邀请或主动激活已存在的账号产生。其场景皆是对产品及账号信息的保密性和安全性要求较高。

2. 同一产品的账号合并与账户打通

当我们了解了几种账号类型后，可能遇到过在一个复杂业务产品的账号体系可能包含以上多个甚至全部的类型。这种情况的出现可能是产品的历史遗留问题造成的或者其本身业务形态决定的。而作为产品经理此时要思考的问题是：是否应该合并这些账号数据？这就涉及到了一个非常关键的字段： 用户唯一标识。

用户唯一标识（UID）：用户在产品中完成账号注册后，自动生成一组特定规则字符组，作为用户账号在产品中的唯一识别标识，不可修改，不可重复，不对用户开放。

合并账号数据其实就是在同一个业务体系或系统下，将同一个用户的不同账号进行数据合并。而账号的合并的本质区别就在于： 是否将同一用户的不同账号的UID进行合并，保持用户在系统中的唯一性。

这里需要产品人衡量与思考的点在于： 不合并或合并，对于业务价值的影响是什么？对于用户价值的影响是什么？

（1）多账号合并：

场景：用户A在同一产品的同一业务系统中有两个相互独立的登录账号，类型相同。

分析思路：这种场景较为常见，比如一个人拥有多个微信号码，QQ号，微博号等。大多数社交类产品是不处理这种一人多账号的情况。那么什么业务场景中会对这类同一用户多账号进行处理合并呢，小编在保险产品中就遇到过这类情况。其处理原因是因为互保产品中，用户作为被保险人会进行实名认证，当被实名认证后，如存在多账号的情况，将较难对其进行保全及理赔的服务维护。多账号的情况会造成保单信息不同步或保险数据冗余。换言之， 当在同一产品的同一业务中，同一用户存在多个账号的情况时，如对该业务数据造成较大影响时，需要对账号数据进行合并处理。此时多账号的合并处理又分为两种：

当需要被合并的账号类型相同，如类型都是手机号码时，其常见的处理手段为选择其中一个手机号码为账号名，其他手机号码注销，并将其对应的账户数据合并同步。
当需要被合并的账号类型不同，如类型一个是手机号码，一个是邮箱号码时，其常见的处理手段为选择其中一个类型为账号主体，其他类型保存，可作为展现数据，也可作为副账号。并将其对应的账户数据合并同步。

在工作中，除了同一产品中同一用户的多账号是否合并的问题，我们还可能遇见同一产品同一账号的多账户是否打通的问题。

（2）多账户打通：

场景：用户A在同一产品的不同业务系统中共用一个登录账号，但业务的账户数据是相互独立，不关联同步。

分析思路：

这种场景也较为常见，比如同一个微信可以在王者荣耀的iOS端和Android端各创建一个账户，登录账号通用，但对应的账户数据相互独立。

那么什么业务场景中会对这类同一用户同一账号在多业务系统的账户数据进行打通处理呢？

这种情况在具有供需交易类业务场景的产品中是较为场景的，比如保险产品，或者二手交易类产品，交易代理人产品。普通C端用户即可是需求方也可以是供给方，俗称小B用户。此时是否要将同一用户在买方业务系统的数据与卖方业务系统的数据打通，在于其相互是否有业务交集或连带的价值体现。

所谓 打通账户数据就是将同一个用户同一账号的在不同业务系统的账户数据进行部分关联和同步。在具有复杂业务场景的产品中，我们想清以上可能会遇的问题及对应解决方案后再进行账号体系的设计会更加的清晰和高效。

总结

每一个行业，每一个产品都有自己的产品特点与业务偏重。产品方法论并不能以点概面，以偏概全。小编在本文分享的账户体系搭建的三步方法论仅针对 偏重业务效率或供需交易的多业务场景的产品设计思路。希望通过本篇分享能为有需要的读者朋友在产品设计之路上有所帮助和借鉴。

#专栏作家#

杨三季，微信公众号：杨三季，人人都是产品经理专栏作家。7年互联网经验的高级产品官，深耕内容电商，互联网保险领域，擅长产品增长、数据分析、中台架构等内容。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自pexels，基于CC0协议

常见分布式应用系统设计图解（十二）：证券交易系统

Sun, 27 Dec 2020 02:09:00 CST

这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。

虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤：

挂单（可以是买单，也可以是卖单）
匹配（或者叫做撮合）
成交
清算

从非功能的角度看，有这样几条需求是这样的系统尤其要强调的：

Consistency，从单个交易的角度来说，主要就是事务性，这是交易系统最最基本的要求。系统不能用了是个灾难，但是如果交易数据错误了这就是个大得多的灾难。
Durability，交易数据必须要持久化。
Throughput，很多股票市场都是对全球开放的，吞吐量意味着对于交易高峰的接纳能力。
Latency，和吞吐量关系密切，可以放在一起讨论。大型交易系统的延迟的最小单位都是按微秒论的。从架构上看这类系统具备一些异步系统（比如下单支付系统）的特点，但是低延迟的要求决定了它的处理方式明显不同。

整个系统来看，包括挂单、匹配、交易和查询这样几个部分。实线部分表示的是写或读写操作，虚线是读操作。
假设有卖家和买家两个用户，分别在不同的时间提交了挂单请求，一个是卖单，一个是买单。
鉴权分为两个部分来完成，基础的部分由 API Gateway 来完成。
Exchange Server 收到原始挂单请求以后，首先调用 Sequencer 去获取一个时间戳，也包括一个基于时间戳生成的 ID。这个时间戳非常重要，因为交易的逻辑里面，对于买单卖单的匹配，以及同价单的优先级，都要基于时间戳的规则来进行。时间戳不能仅仅基于 Exchange Server 自己的时钟来进行，因为每台机器的时钟很可能都不一样。
对于买单，查询账户系统并扣住保证金。
将买单或卖单放入指定的队列，不同的股票有不同的队列来维护。这个队列本身是一个优先级队列，从宏观上看就是 order book。对于买单来说，买价越高越靠前；对于卖单来说，卖价越低越靠前。
不同队列的变更会被 router 通知到不同的匹配（撮合）引擎，这里有多个不同的引擎，每个引擎关注不同的队列变更。在每个引擎的内存中维护一个队列中靠近队列出口的买卖单集合，也是以优先级队列的形式维护在内存中（具体实现可以是堆）。
这样迅速的匹配就可以在内存中迅速发生并完成，内存的数据结构以 Snapshot + WHL 的方式持久化，以达到效率和状态不丢失的平衡。
如果这台机器崩溃，还有集群中的备用机可以顶上，并从上述的 Snapshot + WHL 中恢复之前的状态。这些机器都通过 Node Manager（比如 Zookeeper）来管理。
每次匹配完成，都有一个事件加入到 exchange 的队列中，每只股票都有自己的 exchange 队列。
Router 将队列的事件通知到相应的支付系统和 Tick Calculator。支付系统（或者是清算系统）会完成用户扣款或打款的操作，而 Tick Calculator 会根据交易信息改变当前的股价并持久化到数据库中（这里的数据库需要较大的吞吐量，可以根据股票种类+时间序做 sharding）。
用户可以查询自己的账户变更状况，用户也可以通过 Quotation 系统查询股价变更状况。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接《四火的唠叨》

你可能也喜欢看：

盘点Facebook 、YouTube等主流产品的10大创新设计

Wed, 23 Dec 2020 18:47:25 CST

编辑导读：每个设计师都会有创意灵感缺失、大脑一片空白的状态，这个时候去看看最新的一些设计趋势会是一个寻找灵感的好方法。本文作者梳理盘点了国外主流产品的10大创新设计，希望能帮助解决你设计时遇到的灵感枯竭。

国内的产品设计同质化严重，将众多同类产品放在一起，去除图标和主题色的话，很难区分是哪个App。

设计师的视野如果长期只关注国内，那么设计创新能力很容易被束缚，导致创新能力下降。

应对突发需求，国内没有相对应的竞品，就无法做出可落地的方案。

本篇文章盘点下国外主流产品的10大创新设计，通过本篇文章，希望可以打开视野，提升创新能力。

01 左滑进入聊天界面

Instagram在首页界面，用户左滑进入消息聊天页。这是一种全新的交互形式。

国内的产品，左右滑是切换首页的二级导航。

我第一次使用时不习惯，很容易误操作。当习惯之后，就觉得超级方便。它可以快速地切换到聊天消息页。

为什么Instagram要做这个交互？猜测原因有以下2点：

Instagram发力即时通讯，鼓励用户相互发消息。底部已经有了5个tab，没办法继续增tab。这时候只能想办法找其他流量大的入口。
流量最大的入口毫无疑问是首页。所以Instagram在首页新增手势操作，当用户左滑，就能快速地到达消息聊天页。此方案可以完美的满足业务需求。

02 视频小窗口播放

在YouTube视频详情页，没有视频关闭功能。用户不想看视频时，只能点击播放器左上方的收起箭头。

当用户点击之后，会变成卡片小窗口，进行小窗口播放。如下图所示：

这样设计的好处：

可以让用户边找视频，边观看。尽可能地利用用户时间。
使用户消费更多视频，提升用户的观看效率。

03 推荐视频

YouTube在播放过程中，底部会出现四个视频，用户上滑时全部出现。

用户可以在播放过程中，点击推荐视频观看。

这种设计更加强化推荐视频功能。用户可以在播放过程中，选择更感兴趣的视频。

国内视频产品，在全屏的情况下，无法推荐视频，只能在视频结束后推荐视频。国内这样的好处是可以更聚焦当前视频。

04 筛选订阅视频观看

在订阅内容Tab，用户可以根据标签，进行筛选视频，这种操作可以极大的提升用户查找视频的效率。

像继续观看、未观看内容，这些标签，可以高效，不遗漏地观看订阅up主的视频。

05 提升push打开率

当订阅up主后，push推送没有打开时，会出现消息未打开的图标，用户点击，进入设置页面，进行打开通知设置。

这种设计的好处是：推送设置入口固定展示，用户打开push的概率大大增加。

而push打开率的提升，对提升产品的日活帮助巨大。

06 导航和设置展示在一起

Google Chrome 首页，将用户最常访问的网站和功能项放在一起，如下图所示：

一般来说，国内产品很少将两个不同属性的模块放在一起，这样的话容易被误解为一种类型。

但是为了让用户使用更加方便。Google Chrome将其放在一起，都采用宫格导航的形式，通过图标和背板的不同做了一定程度的区分，用户的体验更加友好。

07 下拉操作

Google Chrome下拉时，展示三个选项，左右滑动选择对应的操作。

这种交互方式，即做到了界面简洁，也做到高效方便使用。

08 为其他app引流

Facebook作为一个超级App，所涉及到的业务庞杂，公司内部各个部门利益复杂。为了业务利益，不同部门组织在不断地博弈。

如下图所示，为了尽可能的给其他业务引流，Facebook底部有6个tab，这在主流产品中是不可思议的存在。

为了给messenger引流，首页右上角增加了一个闪电消息图标，会和messenger App联动，当有新消息时，会出现消息提示。点击跳转到messenger。早期facebook 是将底部一个tab给messenger引流，点击tab，直接跳转到messengerApp。

Facebook的这种导流设计，粗暴高效，短期内使得messenger也成为一个超级app。

09 删除中倒计时

Telegram在删除联系人时，底部会出现倒计时提示，在这个期间，用户可以撤回删除操作。

这种交互设计，使得用户在删除过程中更加有安全感，可以回撤毁灭性操作。

10 一次发多条动态

Twitter在发布动态的时候，可以一次性发送多条，这种设计，可以一次性批量的发送，提升用户效率。

以上就是我发现外国主流产品的创新设计。而这些设计，国内基本没人采用，所以分享出来给大家。

如果大家有其他的发现，欢迎在评论区留言。

#专栏作家#

UX，人人都是产品经理专栏作家。前美团点评高级交互设计师。微信公众号：Echo的设计笔记，欢迎关注

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

用户画像规划流程和方法

Thu, 08 Oct 2020 18:11:43 CST

编辑导语：如今在这个大数据时代，“用户画像”这个词经常出现，它跟精准营销挂钩，可以根据一个人的兴趣、地理位置等进行精确的推送，达到良好的营销效果；本文作者分享了关于用户画像规划的流程和方法，我们一起来看一下。

互联网行业飞速的发展，带动行业业务量激增，同时伴随数据量的增加，互联网各行各业慢慢形成头部企业，2/8原则下长尾企业也越来越多；因此，在大数据量和激烈竞争下，如何更好的对产品进行营销，如何制定价格策略，越来越重要。

那么，如何制定准确的营销和价格，就需要我们针对不同人群，不同个体的特点进行精细化推荐，所要本章介绍了如何进行用户画像。

文章结构：

一、什么是用户画像

用户画像就是对用户按照一定的规则进行统计，划分，从而能够指导用户推荐，客户分层运营，达到营销效果。

昨天：手机APP大爆发是随着手机硬件的发展而发展起来的，发展前期大量APP为抢占市场纷纷上线；用户画像只是为了指导产品设计，主要用于产品设计前夕的用户访谈、用户调研的前期工作，而且一般覆盖的人群比较狭隘，精准度差，产品经理设计产品全靠感觉。

今天：行业竞争越来越大，行业产生的数据量也越来越大，各大公司开始建造自己的数据仓库；那么如何应用数据仓库中的数据，如何进行精细化运营，用户画像越来越受到重视。

明天：随着大数据技术的成熟应用，用户画像标签将越来越多，目前互联网行业中比较成功的标签系统是淘宝的千人千面，技术创新必将推动用户画像的精准度。

二、用户画像常用场景

用户画像概况可应用于一下三个场景：

产品设计：开发前期的产品定位设计；
产品营销：指导运营对特定用户进行推送活动信息，推广信息，个性化推荐等。
产品决策：分析用户画像统计对产品的发展现状和发展趋势进行预测，及时调整产品发展路线。

按照用户标签的生产方式可分为：

统计标签：现有的可以直接从数据中提取出来的标签；包括用户自然属性，用户行为统计等信息。

规则标签：自定义规则进行标签建模；根据业务流程提取需要统计的标签。

算法模型标签：根据机器学习等算法进行用户行为预测分类；具有不确定性、开发周期长、成本高，因此系统中此类标签数量较少。

三、用户画像系统搭建流程

1. 数据采集

对用户数据进行采集，数据预处理，数据挖掘和过滤等手段得出期望的数据集。

用户数据一般分为埋点数据和业务数据：

埋点数据：根据用户的行为特征进行埋点，将得到的数据进行处理存储；
业务数据：用户的姓名、年龄、地理位置等自然属性，同时包括用户购买、用户评价、用户评论等隐形数据。

具体采集方法可以使用如下算法模型：

文本挖掘模型（TF-IDF）：处理文本类型，提取数据信息。

TF是词频，IDF是逆向文件频率，TF-IDF是词频和逆向文件频率的乘积。

Nij就是词i在j文章中出现的次数，分母就是文章的总词数。

D就是语料库中文件总数，下面分母就是词i出现的文档数，然后取对数。

该算法可以直接调用python库Sklearn进行实现，但是该算法比较单一，不考虑词条在文章中的位置，不能准确描述词的重要程度，一般需要结合其他其他算法或者增加权重改进。

聚类算法：聚类算法较多，如ANN神经网络和贝叶斯等，聚类主要是针对冷启动用户、用户分群营销等目的；具体算法相对复杂，目前算法应用多使用python的各种库如Sklearn，包括一些框架tensorflow、caffe等。

相似度模型：一般使用相似度模型进行辅助用户分群，常用的有逻辑回归、线性回归、余弦相似度、皮尔森相似度等。

具体说下余弦相似度：

实例：

用户1和用户2通过公式计算相似度为0.945406，是不是可以解释为两个用户可以划分为同一类人，进行用户分群（计算过程只是用于解释算法，无其他意义）。

若已有数据仓库，数据采集相对比较轻松，可参考文章“ 每日优鲜如何搭建数据仓库？”。

2. 用户维度分析

用户分析具有多维度，随时间更新的特点，包括用户年纪、学历、兴趣、消费水平等都容易变化。

因此维度信息应该随着用户偏好发生变化，因此，在标签系统中需要有新增标签功能。

3. 维度标签化

用户画像最终的实现应该是对维度进行标签化，常用MECE法则进行标签化，防止标签界限不清晰。

标签需要根据需要进行逐级拆分，例如：

4. 标签映射，接口封装

用户画像数据导入服务器中，为后续推荐系统，营销活动服务；封装成API可以作为数据服务的内容，对其他系统提供数据支持。

5. 用户画像评估

对画像进行评估：

用户覆盖率：用户画像具体能够覆盖到多少用户，有些用户画像可能覆盖总用户的50%或者80%；所以覆盖率是用户画像应用的一个评价，覆盖率越高，对后续精准营销的策略选择越准确。

准确率：模型的准确性，如上所述，使用算法模型导致的用户分群错误或者对用户的购买意向预测错误，将直接影响购买率，影响GMV。

可拓展：用户画像在维度刻画应该是可扩展的。

及时性：如果用户画像服务到实时推荐系统中还需要用户画像的及时。

四、总结

用户画像结合大数据技术使用户刻画更加细致、及时，对日趋竞争激烈的互联网浪潮起到越来越重要应用。

本文由@汪仔2296 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议

快速搭建准专业直播间（含直播设备介绍）

Tue, 04 Aug 2020 18:42:27 CST

前言：相信大部分人做直播就是在自己的电脑旁边，弄个麦克风+摄像头，简单直接。但有没有想过做更专业一点的直播间呢？但又不会，而且怕太复杂成本高？本文是自ISUX团队在分享设计直播时，搭建直播间的一些心得，并没有想像中的复杂，成本也不会太高，做直播的你可以尝试一下哦。

一、直播间搭建

目标直播间的搭建设计，以及设备的选型和配置方案需要满足I♡UX AIR的节目直播以及录制需求，包括但不限于：分享类、访谈类、圆桌类等形式。 直播方式 开始直播间搭建前，先要明确以何种方式直播。目前直播方式有两种：手机直播与推流直播。手机直播操作门槛低，实时互动性强；推流直播采用摄像机直播，画面清晰稳定，虽然对设备与技术有更高的要求，但功能多样，可以切换画面，以大特写突出重点，也可以在直播过程中贴图、贴文字。 I♡UX AIR属于授课型直播，嘉宾结合PPT对用户进行内容授课，重点在于PPT也就是内容的展示，同时嘉宾的出镜不可或缺，运营上，也有在直播中贴二维码推广社群以及用户调研等需求，综合以上因素，最后我们决定采用推流直播。

搭建步骤

搭建一个直播间，需要三个方面的准备工作：摄像设备（直播系统），场地&背景布置，灯光布置。搭建周期上，建议提前两周搭建，在正式开播前至少完整测试两次流程，寻找问题，不断优化。 01 摄像设备（直播系统） 硬软件互通的信号转换本质上也是一个小型网络，本次直播包含以下几部分： 软件支持：推流软件OBS、美颜软件YY开播、直播平台看点直播。 摄像：本次直播长达两小时，对画面的清晰度也有要求。我们采用双机位进行直播制作，其中主摄：索尼HXR-NX200 支持长时间录制，副摄：索尼A7R4 镜头清晰度高，作为副机位拍摄特写。将摄像机的视频信号输出到电脑需要采集卡，我们使用了两种采集卡，分别是ACASIS hdmi高清视频采集卡，以及elgato HD60 S+，越贵的采集卡输出的视频质量以及色彩还原度越高。 导播：考虑到视频源的切换需求，同时满足多路视频源的输入，我们配备了导播电脑与多路数字导播设备。 收音：收音使用RODE 罗德wireless go无线麦克风，方便携带，使用简单。 信号系统设计思路&流程： 02 场地&背景布置 场地：我们使用的场地是南山影棚，面积约为15平方米。由于影棚日常需求排期紧张，在搭建上需要尽可能地方便快捷。在预案中我们将影棚区分为：摄制区与器材区 摄制区：嘉宾、电视、背景、装饰 器材区：摄像机、屏反、主播端电脑、导播电脑、灯光 背景：首次试播集我们主要采用静态的布景方式。由于成本较低且对场地的要求较少，操作也便捷，我们选择绒布作为布景材料。与带货直播不同，我们的直播核心在主播和PPT的展示上，为了更好地呈现主播在镜头前的效果与PPT切换的顺畅衔接，背景设置我们采用的是深色系。此外人物的阴影会印在白色背景上，但不会印在吸光的黑色绒布上，这也是我们选择深色系的原因（tips：解决阴影的办法还有一种就是背景与主体的距离要足够远，灯光尽量选择较柔和的光线）。直播过程若出现屏幕反光，对用户对主播都是不好的体验。解决屏幕反光有以下几种办法：将灯光的位置移出屏幕；选择磨砂材质的屏幕；给摄像机安装偏振镜。 直播中：为了嘉宾直播的流畅，我们会提前对好台本，控制时间。可以购买一个提词器装在镜头上，确保嘉宾大多数时间是看着镜头，又能看见台本的内容。 推流流程：首先在直播平台上获取推流地址以及密码，将其输入到推流软件中（obs），确认视频音频信号一切正常后在推流软件上点击开始推流，其次在直播平台上点击开始直播。（tips：网络建议100m以上） 03 灯光系统 主光：爱图仕300d2代 副光：爱图仕120d 轮廓光：爱图仕mini20 原因：该品牌的灯具颜色标准，没有色差，能使直播画面的观感达到最佳效果。 布光方法：三点式布光。三点式布光，又称为区域照明，有三盏灯即可，分别为主体光、辅助光与轮廓光。一般用于较小范围的场景照明，因为直播间的面积有限，三点式布光是最简单且有效的布光方式。其中爱图仕300d2代为主光，与主播呈45度角，爱图仕 120d为副光，将主播脸上的暗部打亮，主副光的光比为2：1。爱图仕mini20为轮廓光，光线打在主播的脑袋后方，为的是使黑色的头发与黑色背景分离开，从而使画面更有层次。灯光尽量使用带柔光的设备，如柔光纸、柔光箱，目的是使主体上的阴影看起来不要太重，达到美观的效果。打光切忌主光方向与摄像机的拍摄方向相同，因为这样会使画面看起来太平而没有层次。 直播间 直播画面

二、直播回顾

I♡UX AIR 是由腾讯ISUX用户体验设计部旗下原创馆举办的，面向广大设计师群体的在线直播论坛活动。I♡UX AIR采用线上直播的方式，邀请资深设计师畅谈有关设计及艺术的话题，用专业案例和系统实践，启迪设计师们的设计思维。本次我们邀请腾讯两位高级设计师为大家分享的是动画与交互设计的经验。前期准备完毕，下午7点20我们的直播正式开始。 7:20PM - 第一位分享嘉宾是腾讯ISUX高级多媒体设计师阿乐。平时我们看到的一则动画只有短短几分钟，背后却经过许多考量，耗费的时间与心血也不少。她先以PUPU蓝莓之夜和MOUSE Q宣传动画为例，详细讲解动画的制作流程。阿乐认为，一个结构清晰的分镜和故事版有助于设计师和设计师的团队迅速把握整个动画的风格/基调/节奏/时长和工作周期。在项目时间充足的情况下，许多人对排期并不是很重视，阿乐强调恰恰这一部分很重要，它能让团队明白你的策划流程。一般来说前期的文案脚本策划会用到至少一周的时间商定，这个部分商定好，进入到动画中期就不能修改了；动画中期要分阶段去总结已完成的内容，提交给项目方看；输出阶段则需要预留一些时间做好音效和各尺寸的适配。好的工具能事半功倍。针对动画制作流程、UI动效设计和团队协作，阿乐还为大家分享了许多高效实用的插件工具，既分析每款工具的优点，也讲述具体的操作方法。这一part的干货太多，屏幕外的观众笔记记到停不下来。 8:10PM - 第二位分享嘉宾是ISUX高级交互设计师歆婉。歆婉从轻聊APP出发，用长达100多页的PPT，倾囊相授自己以及团队设计这款全新社交产品的思路与方法。一般来讲，线上交友会遇到四种连接，一种是连不上的人，一种是坏的连接，一种是虚假的“好连接”，还有一种是真正的连接，而轻聊的目的是让用户找到真正的连接。如何帮助用户找到真正的连接呢？歆婉先简要介绍陌生人引力社交公式，给大家对比男女交友或恋爱的心理差异后，再讲述如何围绕公式去做平衡需求以及解决核心关键点的设计。歆婉指出，人是由两种价值组成的，生物价值和社会价值。陌生人社交男性会更关注生物价值，女性则可能比较关注社会价值。所以在设计用户的个人主页时，在生物价值和社会价值的呈现上做了一个平衡，上层用视频和照片去展示生物价值，下层则展示社会价值，包括公司学校和职位等。用户是有惰性的，在如何激励用户完善资料方面，歆婉也为大家总结了一套方法。本次的分享主题是陌生人社交，设计方法之外，歆婉的讲解里还包含和夹杂了大量的脱单小技巧，不少单身粉丝听完笑称“脱单有望”了。本文分享到这里，感谢阅读！文章来自公众号: 腾讯ISUX(https://isux.tencent.com/articles/i-love-ux-air）

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

方法+实例！新人也能快速掌握的黄金分割构图法

Tue, 24 Dec 2019 18:58:34 CST

自从做设计以来经常会看到一些很高大上的理论，例如：格式塔法则、网格系统、黄金分割法等等，这些词语给人第一印象就是很高大上，很难学会，也有很多设计师看到这些理论就被吓到，认为自己学不会，也不想学，因为理论知识确实是学起来很枯燥。对于初学者的设计师来说，这些理论可以在短时间不用学太多，但是对已经工作几年的设计师来说，这些设计理论知识也是必不可少的。

只有掌握设计中必要的设计知识，才能让自己的设计眼界、技能得到提升。就我个人而言，我在设计初期也是很反感这些所谓的理论知识，对于我来说简单通俗的教学才是最容易让人接受的，理论太深奥，我真的无法从中体会到真正的奥秘。但是，越到后面，我越喜欢研究那些设计理论知识，因为我越来越懂得那些理论的重要性，对我的设计也有很大的帮助。所以今天我采用通俗易懂的方法，教大家去理解和掌握这些高大上的设计理论知识。

今天主要分享我们经常听到的黄金分割构图法。

黄金分割构图法：是一种由古希腊人发明的几何学公式，遵循这一规则的构图形式被认为是「和谐」的，在欣赏一件形象作品时这一规则的意义在于提供了一条被合理分割的几何线段。

黄金分割构图法的基本理论来自于黄金比例 ── 1 : 1.618。

黄金分割构图法运用到海报设计、画册设计、网页设计、绘画、服装设计、logo 设计、电视电影、建筑等等领域。在摄影中也经常会引入黄金分割比例，可以让照片感觉更自然、舒适，更能吸引观赏者，给人一种赏心悦目的视觉感受。

优秀案例分析

我们先赏析一些运用黄金分割法的优秀案例，通过赏析能让我们体会到它的美和重要性。

1. 在海报中的应用

从上面的 2 张人物海报案例中，可以看出都利用了黄金分割螺旋法的技巧，当整张图作为背景时，我们不知道图片主题位置的掌控时，就可以采用黄金分割法的原则。对于人物，可以根据想要突出的人物某一部位，直接采用这种分割方法快速找到版面位置

下面2张海报是通过图形和文字的结合，主题文字排版的位置也都刚刚好是黄金分割的编排，带给人一种美的、舒适的画面感，图片和文字在版面的比例刚好是 1 : 0.618。

2. 在网页中的应用

上面 2 个网页都采用了黄金分割的原则，大体将版面分为图片区+文案区，比例为 1 : 0.618。上面同时采用了网格重叠的形式，而下面的就是最基本的黄金分割比例。版面的编排整体给人一种呼吸感、有序的、层次分明的视觉感受，并且浏览的顺序也是井井有条，如下图阅读顺序指引：

3. 在绘画上的应用

像我们看熟悉的名画「蒙娜丽莎」、「维纳斯的诞生」等也符合黄金分割的比例。黄金分割比例也在这些作品上经过了历史认证，利用黄金分割布局，让画面更耐看、更精致。

4. 在摄影上的应用

在摄影中也经常会引入黄金分割比例，可以让照片感觉更自然、舒适，更能吸引观赏者，给人一种赏心悦目的视觉感受。使用黄金分割的摄影可以制造出一种空旷、寂静的视觉效果，也可以制造出一种特写镜头的效果。不知道怎么拍照好看，学会这一招你的摄影立马高大上。

5. 在建筑上的应用

在建筑设计中的运用也有很多案例，例如上面的金字塔和泰姬陵的多处布局都能看出黄金分割，第三张中国古建筑也都运用了黄金分割构图。自古以来很多文化建筑都采用了这个构图，让建筑看起来更加美观、耐看、精致。

怎么画螺旋黄金分割图

了解了螺旋黄金分割法的用途和好处，我们最主要的是需要知道怎么来画这个螺旋黄金图。

1. 新建画布

2. 画正方形

这里画正方形是最关键的一步，我们只要知道螺旋黄金图的比例就可以很快的画出来。

螺旋黄金图比例为：13 : 8 : 5 : 3 : 2 : 1

只要知道螺旋黄金图的比例我们就可以开始画正方形了，简单的正方形不用我多说吧。我们按 10 倍的比例来画图，简单的意思就是前面的螺旋黄金图比例都乘 10，变为 130 : 80 : 50 : 30 : 20 : 10，再根据这个数字画出 6 个正方形。

正方形画好后按照这个转圈的顺序排好即可。

3. 画圆弧线

正方形画好后，画圆弧线，可以通过画正圆得到。

圆弧线为正圆的四分之一，圆的半径为每个不同正方形的边长，通过不同大小的正方形画出不同大小的圆弧即可。

开始画圆弧：以大正方形的右下角为圆心画正圆，注意相切位置，画好后删除多余的锚点。

△ 圆心位置

△ 相切位置

△ 删除多余锚点

△ 圆弧画完后

到了这一步基本也就出现我们想要的螺旋黄金图，最后只需要将我们的正方形改成描边的模式即可。

△ 最终图形

这里展示一下第二种方法：

螺旋黄金比1 : 1.618在画面中怎么看？

利用黄金分割法的案例实操

说了这么多，没有实际的操作案例你们是不是也很头痛，到底拿到这个技巧怎么去使用呢？在我这里例举一个横版和一个竖版的案例。

1. 横版

找素材

这里找来几张图片，因为是做分析案例，所以我就选择我自己喜欢的图，我选择的是图1。

图片调整

图片确定后，我们就需要把图放到我们的画布中。

但是问题来了，一般我们的设计尺寸基本是不会和找到的素材是一样大的，我们到底要怎样放大图片呢？图片中哪些元素可以忽略，哪些需要重视？螺旋黄金分割法就可以用上了。

利用我们的螺旋黄金分割图，放在我们的版面中。接下来就放大我们的素材图片，分析图片结构。图片上方都是天空，左边是海和天空，只有右下比较复杂，有人和零碎的石头，所以我们这里图片就以人为画面中的焦点，那么我们的螺旋图就需要改变一下位置。

调整图片大小和位置，将图片中的人物放在螺旋图的焦点位置，这样我们的版面就快速地确定了视觉焦点。

文字排版

将文字排版在画布中，再根据文字竖排的样式，和人阅读的习惯，调整图的方向和文字位置，使人看向主题文字，给人一种指引的方向。

总结：主要利用螺旋黄金分割法调整图片的位置焦点，使画面中心达到舒适耐看和精致的视觉效果。

标记分析图：

这个案例我就不做太多的讲解，因为很简单，直接利用螺旋黄金分割构图的方法，将版面按1 : 0.618的比例划分，然后在这个比例画布中排版文案和图片。

2. 竖版案例

图片位置排版

素材选择上面的图2，这里就做一张竖版的海报。

将素材图放在画布中，准备好我们的螺旋黄金分割图，也放在画布中。根据图片本身的特点，人物只有上半身，所以将图片放在底部最为合适。至于人物应该靠中间还是靠边，我们同可以根据图片人物本身的姿势判断，根据人物是微抬头向上看，角度约 30 度，所以选择将人物靠边。

再就是人物具体位置的掌控，我们同样和上面的案例一样直接利用螺旋黄金分割图做参考位置选择，所以就很快找到合适的位置，如上面右图。

填充背景和文案

我们将背景颜色填充为天空统一的色彩，建立网格，将文案排版在画布中，上面主要是海报中的主要文案及主题文案，文案和图片的总体比例为1 : 0.618，遵循我们的黄金法则。

根据图片的气质，图片中的色彩和人物都属于文艺气质，清新、寂静、雅致的感觉，所以我们这里可以选衬线体宋体，结合韩文来体现整体的气质。

效果展示

最后看看海报效果吧，主要讲解螺旋黄金分割图的使用，所以排版方面讲解的比较简单，以及主题文字都采用最简单粗暴的字体，没有过多的修饰。

总结

文章分享了螺旋黄金分割构图的用途，很广泛，包含海报设计、画册设计、网页设计、绘画、服装设计、logo设计、电视电影、建筑、摄影等等领域，以及分享了黄金分割图形的画法，3 个简单的案例实操，利用黄金分割构图来帮助我们构图和排版，最有利于我们对图片焦点位置的选择和排版分布的掌控。

欢迎关注作者的微信公众号：「设计小余」

如何设计一套完整的会员体系？我的5点思考

Wed, 18 Dec 2019 18:01:44 CST

本文作者从自己的工作经验出发，结合案例分享了自己关于会员体系设计的几点思考，与大家分享。

商场购物、生病买药、加油、甚至楼下买早餐……消费几乎就会被问起是否会员的时代，大多时候我们仅仅看到了会员的表层，而它的里层是一整套会员体系。

会员作为用户运营的终端，实现用户价值变现，其中涉及到商业模式、产品、运营、服务等多方协调合作。有过B2B平台的会员产品、零售门店及电商平台的会员设计或运营经验，分享记录一些思考。

一、会员的价值

提升粘性，增加复购：通过权益、激励、关怀等设置让用户持续使用自己的产品，把用户留在自己的生态圈，刺激重复消费。
分层运营：通过会员将用户分层，实现精细化管理，在用户不同生命周期可通过不同权益体系及激励体系激活用户，从而促进用户成长，延缓流失。
异业合作，流量互换：品牌联动，开放异业合作，形成相互导流。如：京东会员与携程会员打造联名会员卡；购买天猫会员拥有爱康国宾体检卡。
场景营销：通过独特消费场景的构建来绑定用户，抢占用户心智，使用户形成使用习惯，从而增加营销触点。例如：买3C数码产品会首先想到京东，买衣服化妆品会首先想到唯品会。
实现二次增长：如今互联网已成为一个存量市场，如何在存量中找增量是企业的第二突破口。一方面，会员可作为企业从传统产品盈利模式到会员收入为主要盈利模式的转变，依托会员费实现营收，如costco；另一方面，会员作为产品的忠实用户，可通过分润激励促使二次传播等。
增加现金流：企业通过收取会员费增加现金流，促进资金周转。

二、会员权益体系的设置

设计会员的权益需思考一个问题：会员设计的商业逻辑。

明确会员设计的商业逻辑首先要确定使用产品的用户画像，其次要确定以用户为中心的服务场景规划，围绕这个场景和人群去设计权益，促活成本和整体设计的核心。当然，会员的商业价值也是在营销中才能体现。

会员权益的分类主要有：

1）身份权益：会员最直观的特权是身份的不同，对应在产品上会有区分于普通用户的身份标识，不同等级或同一企业不同产品的会员又有不同的标识。如QQ会员会有钻石标志，钻石又分绿钻、黄钻等。

2）价格权益：零售三角中的优惠，即与钱相关，要促使用户在你这里消费，价格是其中一个关键因素。价格权益也不是随随便便设置的，需要考虑到成本和营收，企业的最终目的是为了赚钱，前期可以亏钱，但需要有一个回收点，要算清盈亏平衡点，明确投资回报期，真正实现盈利。当然也有的会员单纯是为了丰富产品内容，增加用户粘性，这里不做讨论。

关于价格的权益有很多种，最直接的从产品上体现的价格优惠：会员价、会员折扣、品类折扣等等，间接的有免运费、优惠券、代金券等等，具体的玩法可结合你的会员产品的商业逻辑以及最终要实现的目标来制定。

3）服务权益：提升用户体验设置的权益，如成为携程会员有机场专车接送、候机有豪华候机室、登机有快速通道等。需根据产品特性来设置，如果是个电商平台，可以考虑从物流、售后等设置；功能型产品可设置功能权益，如迅雷会员下载速度更快；内容型产品有针对内容的权益，如爱奇艺会员可以跳过广告，看更多视频的权益等等，根据具体产品来设置。

4）其他权益：和其他产品进行合作，丰富会员权益的同时实现相互导流的功能。如：京东PLUS赠送爱奇艺会员。

三、会员权益体系的实施

1. 产品端

主要从产品底层逻辑、相关系统、展示页面、交互、操作后台等产品的角度进行设计。

产品底层逻辑是重点，基于运营想要实现的功能和达到的目的，产品经理要设计一整套产品底层扭转逻辑，会牵扯到各个系统，例如：

直接售卖的会员产品和销售系统、收银台、订单管理系统等相关；
实现价格权益可能会涉及到优惠券系统等；
服务权益中的专属客服可能涉及到后台会员与客服的绑定、任务派发工作台；
展示页面和交互设计与用户行为路径、习惯、体验、产品的美观度等等相关；
操作后台又涉及到工作人员的配置、数据监控口径等等。

所以看似是一个会员产品，其实背后涉及了很多产品的运转逻辑，产品与产品之间某个系统的打通至关重要。

能用产品解决的事情就尽量系统化、智能化去解决。

2. 运营端

这里的运营指的是宏观层面的运营，包含除产品能实现的功能以外的产品运转的所有阶段。

产品上线前，运营要负责方案的策划（如果是运营发起的项目由运营输出方案），权益的封装，系统人工跑通（和产品的系统跑通不一样，这里主要是各部门的人员协调等工作），组织各条线的产品经理开各种会，规划产品入口、找广告位，营销方案，异业合作导流，产品配置等等。

产品上线后需要监控数据形成日报，根据数据调整运营策略，销售端的激励机制，售后，用户分层运营等等。

四、会员成长体系

简单的会员体系只有权益体系，也是用户最在意的，成为会员可以享受什么好处，如亚马逊和costco，简单粗暴，优势明显。

会员运营也是用户运营，所以针对会员也有会员的分层，在会员的各个生命周期设置不同等级来体现会员的不同价值，延长生命，形成成长体系。

成长值+特殊权益。成长值作为会员等级的划分，可根据用户的行为价值进行赋值。

例如电商平台可以根据提交订单、贡献gmv、购买频率等等行为数据的大小来分层；内容平台可根据打开次数、点击次数、浏览时间等等行为数据来分层；每个动作赋予相应的成长值，有成长值的增加对应也会有成长值的减少（如违返平台规则、删除操作等），根据成长值的不同来规范会员行为，区分会员等级，不同等级的会员又享有不同权益，激励会员不断成长。

五、会员激励体系

如果成长值根据会员行为赋值，那么积分、勋章、大V标识等可作为成长值的展示方式，突出等级制，用产品的形式体现，给用户荣誉感，满足爽点。

有了不同等级，配合激励方式，比如有3000个粉丝就能开通抖音直播，销量、商品数等满足要求能开通淘宝直播。用等级权益去刺激用户不断使用产品，不断获取更多权益，不断成长，形成良性循环。

作者：可乐；微信：zy810331681，微信公众号：可乐的时光旅，欢迎交流~~

本文由 @可乐原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

复盘：一次曲折的会员成长体系设计

Fri, 27 Sep 2019 14:54:18 CST

存量运营开始逐渐流行，各大公司也开始启动自己的用户运营计划了。笔者最近负责了一个会员成长体系的建设，个中曲折，与大家分享。

互联网进入到新的时期，存量意识越来越被人群所重视。这种意识不仅在互联网行业甚嚣尘上，甚至最近一家传统行业的公司找到我，要做一套会员激励体系来激活自己的客户！

这是一家成立16年的文化传播公司，在公益赛事演出传播等领域具有一定的知名度/美誉度，在目标群体中渗透率超过60%，但是近年来竞争对手越来越多，市场环境恶劣，目前正意欲扩展新业务方向。即使这样地位的一家公司目前也面临增长困难的处境，看来19年不是大家的好运年。

公司负责人给了我之前公司内部设计的但并未通过执行的会员体系，隐去关键信息呈现会员福利部分如下：

复古风的完美展现，官僚风扑面而来：

像不像居委会大妈站你面前叫你填表。

这个会员体系最终没通过，也是可以理解的。这份设计只有团队福利与理事福利两个主要模块，内容官方，并不完善。缺乏消费者等级成长带来的身份荣誉感，会员参与感为零，特权感知仅仅停留在价格和少量礼品上。用户与品牌之间的距离感强烈，不吸引人。

开始我的分析，分析方法不是唯一的，本次是一次基于互联网方法论的传统行业实践。

用户会员体系的三个属性： 目标—激励目标行为—激励方法。

一、首先确定目标

结合生命周期理论来做判断，看目前这家公司所在阶段。

企业处在不同的生命周期阶段，结合当时的天时地利人和，才能制定运营策略。

用户生命周期状态见下图：

各个阶段详情：

引入期（启动阶段）：产品刚上线，默默无闻，拓展种子用户。
成长期（成长阶段）：用户增长模式至少找到一条途径，用户量开始稳步增长。
成熟稳定期（成熟阶段）：用户量积累到一定程度，或者触达行业天花板，用户增长缓慢，开始思考变现并进行尝试。
流失期（衰落阶段）：用户增长停止，开始衰减。

不同时期的核心业务指标：

引入期（启动阶段）：种子用户数量，产品功能迭代提升
成长期（成长阶段）：用户数量，用户规模，留存
成熟稳定期（成熟阶段）：变现尝试，提升付费用户数和客单价
流失期（衰落阶段）：减缓用户流失的出现，存量运营

用户运营的关键群体和激励方向：

引入期（启动阶段）：尝鲜者，激励用户体验目标流程，提出建议，指导产品迭代（案例：乌托邦）
成长期（成长阶段）：跨界者，突出产品自身优势特点，强化优势和特点（案例：画世界/彩视）
成熟稳定期（成熟阶段）：上瘾者，复购老客户，刺激持续使用关键功能，促进消费复购（案例：抖音/知乎/快手）
流失期（衰落阶段）：情怀客户，召回，延缓流失，稳定运营（案例：宝宝树）

结合公司实际情况，该公司处于 成熟稳定期，会员体系的目的是提升产品与用户的强关系，继续刺激上瘾，加强品牌认知归属，提升用户留存率以及复购率。

二、确定要激励的目标行为

梳理用户行为的方法：

1. 梳理用户交互可能，尽量细致

从下载注册登陆修改昵称等开始梳理。一般产品经理处会有交互汇总资料。

2. 研究实际的关键路径以及产品设计的预期路径，进行比较

产品经理与数据分析都需要加入这个过程，基于你自己平台用户的特征去分析。比如根据我以往的产品经历，注册以后当天更改头像设定昵称上传个人资料的用户留存更好，互动更多。

根据这些交互特征，可以尝试去激励引导其他用户以提高留存和互动。如果创作内容是我们的关键路径，那么那些热衷内容创作的用户的行为需要重点关注，并将细节添加到会员成长体系中去。

3. 根据产品阶段和实际情况判断激励行为的优先级

我们做过一个七天登录转运的抽奖活动。注册登陆后七天内未登录的，第七天会有推送提示登录浮窗抽奖。奖品当中有商城优惠券，积分等礼品。将提升留存和增加商城漏出两个目标结合进行。

话说回来，手头这家企业需要激励的目标行为是：复购和口播，品牌深化。（传统行业基本都是如此）

三、确定激励方法

1. 用户画像决定行为方式

不同的用户群体对同一刺激的反应完全不同，确定激励方法首先确定目标群体，定性与定量分析相结合。

基于当下业务情况，以及企业能提供的消费数据，结合网络数据，做一个简单的目标用户画像分析。

现有企业用户画像分析：40岁-75岁，高净值中老年人群。女性占比70%，男性占比30%。具体省份分布以企业提供的消费数据为准。东部沿海省份明显消费能力强。

案例：

简而言之，会员用户是：中高端“大妈”和中高端“大叔”。

2. 我们设计的内容一定要满足人性8大核心驱动力

人性是我们一辈子都要去考虑去琢磨的领域。八大核心驱动力可以作为指南针，帮你在无头绪的情况下迅速定位，制定策略。在此简单介绍下，如有兴趣，这些领域需要深入进去仔细理解。

（1）使命——史诗意义和使命感

指人类认为自己正在做的事情，其意义比事情本身更重要，他必须身体力行竭尽全力去完成目标以宽慰他内心的世界。

（2）成就——成长和成就感

指我们通过使用产品取得进展、学习技能、掌握精通和克服困难的驱动力，挑战尤为重要，没有挑战性而获得的奖杯和勋章毫无意义可言。

（3）授权——创意和及时反馈

能驱使玩家全身心投入到创造性的过程，不断找出新事物，并尝试不同的组合。通过不断体验创造的过程，同时注重创造的结果，并获得及时的反馈。

（4）拥有——所有权和拥有感

能驱使玩家拥有或控制某样东西，因此而受到激励。当一个人对某一样物品有拥有感时，自然会产生想要提升该物品的各项性能，这一驱动力是人类积累财富的主要欲望来源，也是玩家积累虚拟货币的主要驱动力。

（5）社交——社交影响和关联性

是人们所有社交因素的集合体，包括师徒关系、社会认同、社交反馈、伙伴关系、竞争关系。对应马斯洛需求层次理论中的受到尊敬、自我实现。

（6）稀缺——稀缺性和渴望

人们想要某样东西原因仅仅是它太罕见，或者无法立刻获得。包括任务机制、游戏时间限制，玩家无法立刻获得奖励，会激励他们一有机会就回到这款产品。即便王者荣耀限制了小孩子玩游戏的时长，可能这反倒会刺激更加痴迷。

（7）未知——未知性与好奇

人们一直受到吸引，是因为不知道接下来会发生什么，这就是未知性与好奇心驱动力。当某样东西超出你日常的模式识别系统，你的大脑便会立即进入高速运转模式，来关注这突如其来的事物。

（8）亏损——亏损与逃避心

我们都不希望坏的事情发生，就是不希望之前的努力白费，不想承认自己做了无用功，正在消失的机会也是对这一核心驱动力的有效应用。比如：特别优惠、限时抢购。（引自《八角形为分析法》）

外在动机是我们最常用的刺激点，外在动机用得太过会损害内在动机。正向刺激好于负向刺激。

结合产品情况和用户画像，确定要使用的动机。我确定使用的动机是：拥有，稀缺，社交，使命。这里带有一定的主观性，不同的运营团队会有不同的选择。

3. 对用户行为进行量化

分等级以及制作积分表。等级是可进不可退的，积分是可进可退的。

一般的用户成长体系两条线并行，等级代表了资历荣耀以及离开成本。

积分代表了用户在平台的货币，在一些时候实行代币作用，兑换权益等，设计者需要注意设计通货膨胀的抑制措施。因本次会员体系设计内容所限，本段内容不进行扩充。

4. 设计

与对方几次深度沟通后，头秃的得出以下结论：传统行业要求简单粗暴，要求一看就懂，不玩概念。以线下进行承接，因为对用户预期不确定，暂时不考虑线上的承接。

本来预计线上公众号做会员承接，福利权益推送平台，同时可为对方新建立公众号进行引流和客户锁定，但是甲方爸爸无情否定了这个提议。

其实不论线上还是线下会员体系，几个基本点还是上面的内容中所阐述的，区别在于线下会员动作刺激会更简单直接，因为线下的目标简单直接，就是复购和消费。

（1）参考京东，知乎，百果园等品牌的会员体系资料，尝试提炼如下方案：

明确的会员等级
会员权益（拥有)（稀缺）
会员活动（稀缺）（社交）
公益基金池（使命）

中高端大妈和中高端大叔，即便是中高端人群，也带有那个时期走过来的人的共性，

（2）会员体系目前有两种：一是免费版。按照消费或者行为升等级，不同等级对应不同权益。

一是付费版。比如最近大火的costco，权益刺激直接显性的产品适合付费会员。

本次设计为免费会员体系，只要之前在该公司消费过，自动成为公司会员，按照消费次数匹配等级。因为考虑到品牌的公益性，不采取金额形式评定级别，金额作为一个展示来具体呈现。

（3）会员权益：体现专属和稀缺的感受，要体现不同等级之间的区别。综合参考costco的会员体系结合个人思考，设计归类如下：

产品类：新产品新功能优先体验，免费试用，孤品预定，限量抢购
服务类：售后退款优先处理，退货免运费，额外修理服务，上门配送
活动类：会员日，会员价，会员生日福利，节日福利
金额类：折扣券，优惠券，满减券，积分换礼，邀请返现
异业合作：同一用户画像用户的其它需求

（4）在设计的过程中同时考虑到活动体验官和积分兑换两个补充内容。

活动体验官可与该公司新开发的中高端旅游项目的推广相结合，为高端客户提供仪式感参与感，对提升客户的品牌黏度是一种有效途径，方便激活核心客户。

积分兑换绑定客户给客户带来额外惊喜的作用有目共睹，线上产品根据用户行为生成积分再进行反馈，形成正向反馈，基于RFM模型来看，积分策略对于中段用户有很好的提升刺激做用。

积分体系上线后，我们以往产品中的关键指标大幅提升，同时用户会得到相应福利，反馈是双向正面的。

但最终结合这家企业的情况，这两种方式并不适合他们。这家公司更倾向于采用邮寄手册+电话维护的方式进行目前的客户管理，很谨慎，但这也是他们擅长的部分。

会员权益可根据情况进行升级调整，一般来说，如非行业霸主，不可将权益降级只能升级。品牌的搭建需要一点一滴维护，任重道远。

总结

会员体系和会员关系管理是一家企业发展到一定阶段必须要重视的部分。这个体系不是一成不变的，需要根据企业业务情况与时俱进。

文章开头就有提到，对于一般的企业来说，目前是存量的争夺时期。通过强调和优化会员体系提高用户留存是不得不去尝试的方法。

传统行业与互联网行业有区别也有融合：

对待互动性的区别，传统行业更强调单向传输，让用户接受并不真正在意反馈。
平等思维，传统行业把用户当作圈养的群体。
互联网产品可在使用过程中对用户进行教育，传统行业的教育用户的机会非常少，更注重直接缩短买卖过程，极为在意成交。
传统行业更强调客户概念，互联网企业更强调用户概念。客户可以带来直接收益是公司的命脉，用户可以带来流量收益是互联网概念的直接表现。可以看到，目前互联网企业迫于变现压力越来越强调客户与用户概念以及运营手段的区分。

多接触不同行业是有必要的，避免陷入惯性思维。

该行业内暂无竞品可对比参考。如有条件，一定要研究对比竞品的设计理念和细节。知己知彼百战不殆。

本文由 @伙夫安妮原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

详解安防产品之“雪亮工程”

Mon, 04 Nov 2019 10:50:46 CST

本文介绍了与安防产品相关的雪亮工程，以及它的特点、应用场景与发展趋势。

01 什么是“雪亮工程”

2015年6月，中共中央政治局委员、中央政法委书记孟建柱到山东临沂平邑县调研时对“雪亮工程”信息化，整合资源、降低成本，提高治安防控能力的经验做法，给予充分肯定/
2016年10月，全国综治“江西会议”指出，中央已将“雪亮工程”建设纳入“十三五”规划，并作为综治工作当前和今后一个时期的重点工作部署推进。
2018年1月2日，《中共中央国务院关于实施乡村振兴战略的意见》建设平安乡村，推进农村“雪亮工程”建设。

“雪亮工程”是以县、乡、村三级综治中心为指挥平台、以综治信息化为支撑、以网格化管理为基础、以公共安全视频监控联网应用为重点的“群众性治安防控工程”。

一句话概括：“雪亮工程”即建设覆盖到村及院落的视频监控点位的“群众的眼睛是雪亮的”。

“雪亮工程”通过三级综治中心和四级综治信息平台建设，结合群防群治、“一户一档”等工作开展，把治安防范措施延伸到群众身边，发动社会力量和广大群众共同监看视频监控，共同参与治安防范，从而真正实现社会治安防控”全覆盖、无死角”。

02 “雪亮工程”的特点

传统安防工程主要是以视频监控为主，并且需要配备专人进行视频监看。

“雪亮工程”监控平台不仅仅能够实现最基础的视频监控，村民通过有线电视机顶盒即可实时监看小区、社区视频监控图像，并可实现“一键报警”。实现人人可监视，处处可监看，让农村百姓实施监督、参与监督。雪亮能够实现安卓手机和苹果手机智能终端的APP无缝接入，通过手机平台即可实现“可视对讲、语音广播、云台控制、一键报警”等强大功能。

项目具有以下特点

（1）让村民通过村务服务监督平台，了解惠民政策、公开公示和共建工程动态，通过这套系统，村民们打开电视机便能看见村里几个重要路口的实时影像。如果村民发现安全隐患，便可立即通过平台与警务室进行视频通话，直接报警。

（2）将短信推送与“雪亮”工程有机结合，实现了信息化值守，大大节约了人工成本，值得大力推广。

（3）利用有线电视和智能手机推动视频监控入户到人，建成综治主导、社会协同、公众广泛参与的综治项目。

（4）与公安“天网工程”互补的群众性综治“雪亮工程”建设，能进一步提升了立体化治安防控体系实战效能。

03 雪亮工程应用场景

普通用户可使用机顶盒查看所在村、社区、街道附近的相关摄像机的实时视频，可以方便用户对周边相关场所现在情况的了解。如：当用户想要查看自己小孩是否在某个公共区域玩耍，或在学校的情况，都可以通过我们的平台进行查看。

场景一雪亮上电视

用户可以通过手机随时随地的查看自己住所周边的相关视频，从而给用户的出行及所希望了解的其他内容提供及时、方便的信息等。

场景二雪亮上手机

村综治办监控值班室，配备一台电脑和显示屏，可实时显示各路视频监控信号，村综治办接收村民的报警信号，并可向上级报警。

通过监控画面，监控人员能在第一时间全面掌握辖区内的治安状况，为及时出警、准确到达事发地段提供可靠依据。

村中各监控装置的实时视频信号，值班人员可以控制云台，操控每一台监控设备。

当居民发出报警信息时，在大屏幕上展示地图上报警地点和联系电话，并有语音提示。值班员可以通过电话与报警的村民沟通，确定出警方式。

当治安事件发生后，村值班人员可调用辖区监控点实况录像，协助事件的调查。对辖区内的难以处理的异常事件上报上级综治办，请求指导和援助。

场景三雪亮工程村综治办监控值班室

04 “雪亮工程”的商业模式

政府采购模式；EPC总包，包括项目的设计、采购、施工、试运行等全过程的总承包；
BT模式，政府购买服务；总投资+资金占有率（5年，4.9%左右），多数按照5~10年期等额本息的方式每年返还；
PPP模式，政府与社会资本化以合资公司的方式，政府出让特许经营权（SPV），按照出资比例利润分成，一般这种模式10年及以上多一些；

利润点

网络带宽利润；视频类的项目，离不开前端设备的网络接入，运营商有天然优势；
设备利润；设备厂家有天然优势，集成商能否拿到设备的低价；
平台定制化建设利润；例如与现有政府信息化系统的对接或一些具有地方特色的定制化功能开发（人脸识别、大数据预判平台等）；
项目利润；政府有预算支持采购，不采用购买服务模式，这种模式最讨人喜，取决于谁的商务关系硬，但也竞争最为激烈；
工程建设与系统维护利润。

05 未来的发展趋势

过去

平安城市建设以城市为主，以道路、重点区域监控建设为主，且主要注重对警务事件的监控管理，而忽视了农村、社区的安防建设以及非警务事件的处理，往往等事件发生或者矛盾激化才采取措施。

现在

通过雪亮工程，以农村、社区为重点，对重要部位、重要场所、农村薄弱地区进行视频监控建设，响应国家“十三五”治安防控体系建设要求，实现城乡治安防控建设一体化，达到预警、预测、预防的效果，提高群众满意度。

将来

通过平安城市和雪亮工程，城乡音视频监控一体化建设完成纵向贯通省、市、县、乡镇、村、网格，横向联通综治中心、公安指挥中心、政务服务中心、数字化城管中心及各服务部门的公共安全视频系统联网应用，实现城乡大联动。最终实现“全域覆盖、全网共享、全时可用、全程可控”。

作者：博哥，微信公众号：博之大者。4年开发，6年安防、通信行业的产品及管理经验。致力于懂技术、懂管理、爱生活的有为青年，愿与大家一起进步成长！

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unspalsh, 基于CC0协议。

HTTP的前世今生

Tue, 01 Oct 2019 19:21:10 CST

HTTP (Hypertext transfer protocol) 翻译成中文是超文本传输协议，是互联网上重要的一个协议，由欧洲核子研究委员会CERN的英国工程师 Tim Berners-Lee v发明的，同时，他也是WWW的发明人，最初的主要是用于传递通过HTML封装过的数据。在1991年发布了HTTP 0.9版，在1996年发布1.0版，1997年是1.1版，1.1版也是到今天为止传输最广泛的版本（初始 RFC 2068 在1997年发布，然后在1999年被 RFC 2616 取代，再在2014年被 RFC 7230 / 7231/ 7232/ 7233/ 7234/ 7235取代），2015年发布了2.0版，其极大的优化了HTTP/1.1的性能和安全性，而2018年发布的3.0版，继续优化HTTP/2，激进地使用UDP取代TCP协议，目前，HTTP/3 在2019年9月26日被 Chrome，Firefox，和Cloudflare支持，所以我想写下这篇文章，简单地说一下HTTP的前世今生，让大家学到一些知识，并希望可以在推动一下HTTP标准协议的发展。

HTTP 0.9 / 1.0

0.9和1.0这两个版本，就是最传统的 request – response的模式了，HTTP 0.9版本的协议简单到极点，请求时，不支持请求头，只支持 GET 方法，没了。HTTP 1.0 扩展了0.9版，其中主要增加了几个变化：

在请求中加入了HTTP版本号，如： GET /coolshell/index.html HTTP/1.0
HTTP 开始有 header了，不管是request还是response 都有header了。
增加了HTTP Status Code 标识相关的状态码。
还有 Content-Type 可以传输其它的文件了。

我们可以看到，HTTP 1.0 开始让这个协议变得很文明了，一种工程文明。因为：

一个协议有没有版本管理，是一个工程化的象征。
header是协议可以说是把元数据和业务数据解耦，也可以说是控制逻辑和业务逻辑的分离。
Status Code 的出现可以上请求双方以及第三方的监控或管理程序有了统一的认识。最关键是还是控制错误和业务错误的分离。

（注：国内很多公司HTTP无论对错只返回200，这种把HTTP Status Code 全部抹掉完全是一种工程界的倒退）

但是，HTTP1.0性能上有一个很大的问题，那就是每请求一个资源都要新建一个TCP链接，而且是串行请求，所以，就算网络变快了，打开网页的速度也还是很慢。所以，HTTP 1.0 应该是一个必需要淘汰的协议了。

HTTP/1.1

HTTP/1.1 主要解决了HTTP 1.0的网络性能的问题，以及增加了一些新的东西：

可以设置 keepalive 来让HTTP重用TCP链接，重用TCP链接可以省了每次请求都要在广域网上进行的TCP的三次握手的巨大开销。这是所谓的“ HTTP 长链接” 或是 “ 请求响应式的HTTP 持久链接”。英文叫 HTTP Persistent connection.
然后支持pipeline网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。（注：非幂等的POST 方法或是有依赖的请求是不能被pipeline化的）
支持 Chunked Responses ，也就是说，在Response的时候，不必说明 Content-Length 这样，客户端就不能断连接，直到收到服务端的EOF标识。这种技术又叫 “ 服务端Push模型”，或是 “ 服务端Push式的HTTP 持久链接”
还增加了 cache control 机制。
协议头注增加了 Language, Encoding, Type 等等头，让客户端可以跟服务器端进行更多的协商。
还正式加入了一个很重要的头—— HOST这样的话，服务器就知道你要请求哪个网站了。因为可以有多个域名解析到同一个IP上，要区分用户是请求的哪个域名，就需要在HTTP的协议中加入域名的信息，而不是被DNS转换过的IP信息。
正式加入了 OPTIONS 方法，其主要用于 CORS – Cross Origin Resource Sharing 应用。

HTTP/1.1应该分成两个时代，一个是2014年前，一个是2014年后，因为2014年HTTP/1.1有了一组RFC（ 7230 / 7231/ 7232/ 7233/ 7234/ 7235），这组RFC又叫“HTTP/2 预览版”。其中影响HTTP发展的是两个大的需求：

一个需要是加大了HTTP的安全性，这样就可以让HTTP应用得广泛，比如，使用TLS协议。
另一个是让HTTP可以支持更多的应用，在HTTP/1.1 下，HTTP已经支持四种网络协议：
- 传统的短链接。
- 可重用TCP的的长链接模型。
- 服务端push的模型。
- WebSocket模型。

自从2005年以来，整个世界的应用API越来多，这些都造就了整个世界在推动HTTP的前进，我们可以看到，自2014的HTTP/1.1 以来，这个世界基本的应用协议的标准基本上都是向HTTP看齐了，也许2014年前，还有一些专用的RPC协议，但是2014年以后，HTTP协议的增强，让我们实在找不出什么理由不向标准靠拢，还要重新发明轮子了。

HTTP/2

虽然 HTTP/1.1 已经开始变成应用层通讯协议的一等公民了，但是还是有性能问题，虽然HTTP/1.1 可以重用TCP链接，但是请求还是一个一个串行发的，需要保证其顺序。然而，大量的网页请求中都是些资源类的东西，这些东西占了整个HTTP请求中最多的传输数据量。所以，理论上来说，如果能够并行这些请求，那就会增加更大的网络吞吐和性能。

另外，HTTP/1.1传输数据时，是以文本的方式，借助耗CPU的zip压缩的方式减少网络带宽，但是耗了前端和后端的CPU。这也是为什么很多RPC协议诟病HTTP的一个原因，就是数据传输的成本比较大。

其实，在2010年时，Google 就在搞一个实验型的协议，这个协议叫 SPDY，这个协议成为了HTTP/2的基础（也可以说成HTTP/2就是SPDY的复刻）。HTTP/2基本上解决了之前的这些性能问题，其和HTTP/1.1最主要的不同是：

HTTP/2是一个二进制协议，增加了数据传输的效率。
HTTP/2是可以在一个TCP链接中并发请求多个HTTP请求，移除了HTTP/1.1中的串行请求。
HTTP/2会压缩头，如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的HPACK算法（参看 RFC 7541 附录A）
HTTP/2允许服务端在客户端放cache，又叫服务端push，也就是说，你没有请求的东西，我服务端可以先送给你放在你的本地缓存中。比如，你请求X，我服务端知道X依赖于Y，虽然你没有的请求Y，但我把把Y跟着X的请求一起返回客户端。

对于这些性能上的改善，在Medium上有篇文章你可看一下相关的细节说明和测试“ HTTP/2: the difference between HTTP/1.1, benefits and how to use it”

当然，还需要注意到的是HTTP/2的协议复杂度比之前所有的HTTP协议的复杂度都上升了许多许多，其内部还有很多看不见的东西，比如其需要维护一个“优先级树”来用于来做一些资源和请求的调度和控制。如此复杂的协议，自然会产生一些不同的声音，或是降低协议的可维护和可扩展性。所以也有一些争议。尽管如此，HTTP/2还是很快地被世界所采用。

HTTP/2 是2015年推出的，其发布后，Google 宣布移除对SPDY的支持，拥抱标准的 HTTP/2。过了一年后，就有8.7%的网站开启了HTTP/2，根据这份报告，截止至本文发布时（2019年10月1日），在全世界范围内已经有41%的网站开启了HTTP/2。

HTTP/2的官方组织在 Github 上维护了一份各种语言对HTTP/2的实现列表，大家可以去看看。

我们可以看到，HTTP/2 在性能上对HTTP有质的提高，所以，HTTP/2 被采用的也很快，所以，如果你在你的公司内负责架构的话，HTTP/2是你一个非常重要的需要推动的一个事，除了因为性能上的问题，推荐标准也是架构师的主要职责，因为，你企业内部的架构越标准，你可以使用到开源软件，或是开发方式就会越有效率，跟随着工业界的标准的发展，你的企业会非常自然的享受到标准所带来的红利。

HTTP/3

然而，这个世界没有完美的解决方案，HTTP/2也不例外，其主要的问题是：若干个HTTP的请求在复用一个TCP的连接，底层的TCP协议是不知道上层有多少个HTTP的请求的，所以，一旦发生丢包，造成的问题就是所有的HTTP请求都必需等待这个丢了的包被重传回来，哪怕丢的那个包不是我这个HTTP请求的。因为TCP底层是没有这个知识了。

这个问题又叫 Head-of-Line Blocking问题，这也是一个比较经典的流量调度的问题。这个问题最早主要的发生的交换机上。下图来自Wikipedia。

图中，左边的是输入队列，其中的1，2，3，4表示四个队列，四个队列中的1，2，3，4要去的右边的output的端口号。此时，第一个队列和第三个队列都要写右边的第四个端口，然后，一个时刻只能处理一个包，所以，一个队列只能在那等另一个队列写完后。然后，其此时的3号或1号端口是空闲的，而队列中的要去1和3号端号的数据，被第四号端口给block住了。这就是所谓的HOL blocking问题。

HTTP/1.1中的pipeline中如果有一个请求block了，那么队列后请求也统统被block住了；HTTP/2 多请求复用一个TCP连接，一理发生丢包，就会block住所有的HTTP请求。这样的问题很讨厌。好像基本无解了。

是的TCP是无解了，但是UDP是有解的！ 于是HTTP/3破天荒地把HTTP地底层的TCP协议改成了UDP！

然后又是Google 家的协议进入了标准 – QUIC （Quick UDP Internet Connections）。接下来是QUIC协议的几个重要的特性，为了讲清楚这些特性，我需要带着问题来讲（注：下面的网络知识，如果你看不懂的话，你需要学习一下《 TCP/IP详解》一书（在我写blog的这15年里，这本书推荐了无数次了），或是看一下本站的《 TCP的那些事》。）：

首先是上面的Head-of-Line blocking问题，在UDP的世界中，这个就没了。这个应该比较好理解，因为UDP不管顺序，不管丢包（当然，QUIC的一个任务是要像TCP的一个稳定，所以QUIC有自己的丢包重传的机制）
TCP是一个无私的协议，也就是说，如果网络上出现拥塞，大家都会丢包，于是大家都会进入拥塞控制的算法中，这个算法会让所有人都“冷静”下来，然后进入一个“慢启动”的过程，包括在TCP连接建立时，这个慢启动也在，所以导致TCP有一些时候性能也不行。QUIC才不管这个，是个相对比较激进的协议。QUIC有一套自己的丢包重传和拥塞控制的协，一开始QUIC是重新实现一TCP 的 CUBIC算法，但是随着BBR算法的成熟（BBR也在借鉴CUBIC算法的数学模型），QUIC也可以使用BBR算法。这里，多扯几名， 从模型来说，以前的TCP的拥塞控制算法玩的是数学模型，而新型的TCP拥塞控制算法是以BBR为代表的测量模型，理论上来说，后者会更好，但QUIC的团队在一开始觉得BBR不如CUBIC的算法好，所以没有用。现在的BBR 2.x借鉴了CUBIC数学模型让拥塞控制更公平。这里有文章大家可以一读“ TCP BBR : Magic dust for network performance.”
接下来，现在要建立一个HTTP的连接，先是TCP的三次握手，然后是TLS的三次握手，要整出六次网络交互，一个链接才建好，虽说HTTP/1.1和HTTP/2的连接复用解决这个问题，但是基于UDP后，UDP也得要实现这个事。于是QUIC直接把TCP的和TLS的合并成了三次握手。

所以，QUIC是一个在UDP之上的伪TCP +TLS +HTTP/2的多路复用的协议。

但是对于UDP还是有一些挑战的，这个挑战主要来自互联网上的各种网络设备，这些设备根本不知道是什么QUIC，他们看QUIC就只能看到的就是UDP，所以，在一些情况下，UDP就是有问题的，

比如在NAT的环境下，如果是TCP的话，NAT路由或是代理服务器，可以通过记录TCP的四元组（源地址、源端口，目标地址，目标端口）来做连接映射的，然而，在UDP的情况下不行了。于是，QUIC引入了个叫connection id的不透明的ID来标识一个链接，用这种业务ID很爽的一个事是，如果你从你的3G/4G的网络切到WiFi网络（或是反过来），你的链接不会断，因为我们用的是connection id，而不是四元组。

然而就算引用了connection id，也还是会有问题，比如一些不够“聪明”的等价路由交换机，这些交换机会通过四元组来做hash把你的请求的IP转到后端的实际的服务器上，然而，他们不懂connection id，只懂四元组，这么导致属于同一个connection id但是四元组不同的网络包就转到了不同的服务器上，这就是导致数据不能传到同一台服务器上，数据不完整，链接只能断了。所以，你需要更聪明的算法（可以参看 Facebook 的 Katran 开源项目）

好了，就算搞定上面的东西，还有一些业务层的事没解，这个事就是 HTTP/2的头压缩算法 HPACK，HPACK需要维护一个动态的字典表来分析请求的头中哪些是重复的，HPACK的这个数据结构需要在encoder和decoder端同步这个东西。在TCP上，这种同步是透明的，然而在UDP上这个事不好干了。所以，这个事也必需要重新设计了，基于QUIC的QPACK就出来了，利用两个附加的QUIC steam，一个用来发送这个字典表的更新给对方，另一个用来ack对方发过来的update。

目前看下来，HTTP/3目前看上去没有太多的协议业务逻辑上的东西，更多是HTTP/2 + QUIC协议。但，HTTP/3 因为动到了底层协议，所以，在普及方面上可能会比 HTTP/2要慢的多的多。但是，可以看到QUIC协议的强大，细思及恐，QUIC这个协议真对TCP是个威胁，如果QUIC成熟了，TCP是不是会有可能成为历史呢？

未来十年，让我们看看UDP是否能够逆袭TCP……

(全文完)

关注CoolShell微信公众账号和微信小程序

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

复盘：如何从0-1设计SaaS行业CRM系统

Wed, 02 Oct 2019 11:07:28 CST

笔者复盘了做一个SaaS行业CRM系统的关键节点以及重要事项。

从项目启动到现在差不多大半年的时间，这半年中我经历了CRM系统从0-1的搭建过程。不过与以往接触的CRM系统不同，这次我主要负责的系统是面向SaaS行业。从产品形态上看，SaaS行业属于B2B行业大类，但也有着其独有的特征。

这篇文章我希望通过讲故事的方式分享我在V1.0版本时遇到的业务问题以及解决方案，大家如果有不一样的见解，也欢迎大家在评论区进行问题探讨。

一、产品V0.1版本的建立

在刚到公司之前，公司主要以某细分领域的定制化项目作为主要的盈利方式。在这之后公司希望结合自身领域上的优势将自己的产品SaaS化，这其中一方面是出于对产品通用性角度考虑：在这个细分领域中各企业的业务流程有着较多的相似之处，实现产品通用化是可行的；当然更重要的是从商业角度考虑，这样能够降低产品的开发与维护成本；同时通过按需订阅的方式能够争取更多中小“长尾组织”的有限预算。

我在来到公司负责的第一个项目就是将系统架构进行SaaS化改造：首先按照战略思路将产品功能划分为基础服务级、应用模块级，同时支持高可配置化的菜单及功能来满足多租户不同的业务需求，之后将系统权限改造为多租户权限模式，将应用模块与租户ID做灵活关联从而实现按需购买服务。

有关SaaS产品化改造的话题我先大概说到这，更具体的改造细节我会在后面的文章中为大家介绍。

而在改造的过程中，就逐渐有了CRM系统雏形：系统权限在划分为多租户后，需要企业后台系统需要有设置多租户入驻信息及租户开通功能，这也就完成了客户信息的采集与创建，因此我也称之为CRM产品的V0.1版本。

二、SaaS业务的快速扩张促进项目启动

由于是SaaS产品的初步尝试，公司在商业模式上并没有在初期就选择付费，而是希望通过免费的形式获得更高的市场占有率，树立品牌认同；同时持续打磨产品，而后再逐步将产品模块升级，并在原有的基础上做增值服务。

这一打法在市场上确实获得了预期成效：我们在短短一年多的时间内从40w用户量暴涨至240w，租户数也达到将近1w，用户量远远超过入驻即付费的其他平台。

却也随之带来更多业务问题：由于大部分客户是免费入驻与使用产品，产品的运营成本不降反升。因为一方面客户的免费入驻并不能为公司带来收入；与此同时，在售后服务上又需要投入更多的时间和人力成本来培训客户，并要及时解答客户提出的问题。

这时有的同学会问：为什么不通过植入广告的方式来缓解资金压力呢？

我们的是to B的商业软件产品，主要以提升工作与管理效率为目的；
我们所处的行业十分敏感，不宜通过商业广告的形式进行变现。

由于收益增长的压力与成本的提升，导致市场与客户运营部门没有足够的弹药扩充人手，总共不超过12个人的团队在产品上线初期，每天需要应对客户不断打来的电话，同时需要参与开拓市场与售前咨询任务，可谓是身兼多职。

后来，在线上产品慢慢打磨与过渡接近完整后，公司希望能够通过对部分应用采用增值服务的形式实现SaaS产品的业务增长。而争取的客户对象则主要是来自平台在搭建初期积累的这些线索客户，使之成为高意向潜在付费客户并完成付费转化。

这是面临的问题是：如何通过现有的团队来管理与维护如此大体量的客户？这需要引入客户管理系统来解决此问题。

三、项目启动前的研讨：自主研发还是外部采购？

关于系统是通过自研还是外采的问题，我们团队之间讨论过多次。相信很多公司也会有此困惑，如果选择外采，其优势是团队将节省大量的研发及时间成本，但是需要找到与产品业务契合的系统才能有效实施。

最终我们选择了自研系统，原因有以下几点：

产品运营初期，产品战略及商业模式还有待市场考证，需要快速的响应市场快速迭代
市面上的通用CRM系统不能满足当前的业务需求
系统与自身产品的连接较为紧密，需要提供丰富的接口来支持，同时也要相应接口的不断变化

四、明确项目核心问题

在项目启动后，系统待解决的核心问题是：在销售人员较少的情况下，通过系统提升客户营销与管理效率，并最终并实现业务增长。

基于这个核心问题拆解成两个部分，如下图所示：

4.1 业务流程再造

由于是从0到1运营一条新的SaaS产品线，我们需要基于全新的产品形态设计与以往项目型销售不同的业务流程。为此我也做了很多产品调研，从商业模式上分析SaaS产品与原先销售模式的不同。

首先相比于项目型销售，SaaS产品的客单价较低，更多的收入将来自于客户的续费与增购。这就意味着以客户为中心的销售模式将确立主导地位。所谓“以客户为中心的销售模式”的核心就是要参与客户的全生命周期，了解客户在使用过程中产生的各种需求，并及时快速的响应需求。通过这样的销售模式才能真正服务好客户，只有通过这样的方式，才能获得更多的二次收益。

SaaS产品与项目型销售的第二点不同，是更为注重数据驱动而非营销驱动。用户在使用SaaS产品的替换成本会更低，即便客户在销售人员的说服下完成了首单消费，如果产品并不是他们真正需要的，也会直接流失掉。因此SaaS产品需要借助更多的数据挖掘潜在客户而非完全通过线下完成。

基于主流SaaS销售模式调研，并结合公司在组织人员架构与现有业务现状，我对业务流程进行了重新梳理，流程大致如下图所示：

在图中我列出了几个重要的流程节点：

4.1.1 线索获取

考虑前期有限的推广资源以及较低的投资回报率，公司并没有使用付费的市场推广形式。好在产品较好的口碑与高日活量使得在百度搜索的权重较高，加上产品是免费使用，每日的入驻用户仍保有稳定增长。

4.1.2 线索认证

对于线索认证这一阶段的考虑是通过系统目标账户营销（ABM）+人工的方式筛选合格线索（MQL）：

其中系统目标账户营销（ABM）是指通过系统获取用户在浏览付费增值应用时的浏览记录与习惯，通过系统规则标记为潜在客户；
合格线索（MQL）则是根据销售人员以往的经验，手动录入潜在客户信息。

两种潜在客户获取方式分别存成独立的数据表单放入数据库中。

这样做的好处是能够最大程度上起到辅助销售的作用，减少销售人员在客户跟踪与识别上的工作量；在此同时，通过数据还可以挖掘出销售人员在客户识别时的视线盲区，不放过任意一个线索机会。

4.1.3 商机客户转化

严格意义上，线索质量验证与培育应由市场部SDR来完成，而后将合格线索转到销售人员手中做商机客户的转化。但由于产品初期并未配备相关人员，这两个步骤都由同一个销售人员共同完成。

4.1.4 成交客户的续费与增购

前面说到，SaaS产品的大部分收入来自于此步骤，因此在客户完成首单交易后需要做更多的工作，以便实现客户留存并尽可能使之成为高净值推荐客户（NPS）。

在业务实施的开始阶段，我与客户运营部的负责共同制定了详细的相关工作内容及流程：包括客户的回访与跟进频次，产品bug与需求的反馈，客户培训与二次销售流程等等。结合用户需求及业务场景设计产品解决方案，具体解决方案我也会在后面的内容中提到。

4.2 组织架构的优化

在制定了新的业务流程之后，在组织架构层面也会随之调整。客户运营部门明确了岗位角色与分工，一部分人员被拆分到专门负责客户拓展与售前咨询的销售团队；另一部分进入负责售后咨询而增购的客户成功团队。

五、产品路线图规划

在明确了待解决的业务问题后，我们将产品明确定位在“以客户为中心”的核心思路。也就意味着产品功能会在紧张的开发排期中作出取舍。保留现阶段最需要解决的业务问题，同时砍掉与之无关的功能，将视角聚焦在“客户”上。如下图所示：

图中简要列出了一个产品结构示意图，从中可以大致了解产品的全貌。从整体架构上看，我将线索管理与客户成功管理拆分为两个模块，并按照各业务部门职能将权限按照整体模块分配给销售部与客户成功部。当客户处于未达成交易状态时，该条客户会存入线索管理中由销售部跟进，而当客户完成首单后，客户数据将流转至客户成功管理中挖掘二次销售商机。

此外，灰色部分代表暂时舍弃掉的功能，至于舍弃的原因在于客户营销与拓展部门的人数远没有达到通过系统管理的程度，因此暂时不需要开发相应功能。

5.1 线索管理与权限管理

线索管理是销售过程管理中最传统，同时也是最经典的部分；而权限管理是所有后台管理系统的必备工具，基于RBAC的权限设计方法也比较固定和基础，这两部分内容在很多CRM产品相关文章中都有涉及，我就在此不做过多描述。

5.2 客户成功管理

客户成功管理是SaaS领域最重要的部分，一个好的CSM业务体系需要介入客户的完整生命周期中，包括客户的初期促活、中期的客户意见反馈与使用指导。只有服务好客户的每一步，才能最终达成续费或增购的最终业务目的，实现企业收入增长。

在客户流转至客户成功模块后，平台会对客户的使用情况进行数据监控，让客户成功经理实时了解用户的使用情况；并通过系统规则提示哪些客户疑有流失征兆，并设置流失预警，提醒他们及时跟进。

此外，根据特定的业务场景我将商机管理模块放入客户成功模块，使得正式客户表与商机形成1对n的关系，并间接与订单关联；而处于未达成交易状态的潜在客户则直接与订单1对1关联，用户可直接由线上创建订单。这样做的考虑是既能够简化首单流程，又能在客户成功阶段增加对商机过程的管理。为项目后期的客户终身价值（CLV）建模提供较为准确的数据依据。

智能分析模块是CRM产品中非常重要的一部分，但由于初版上线时间紧任务重，以及数据的不完整，因此将放入二期需求；并在一期做好客户信息及销售过程数据的整合与沉淀，搭建数据仓库。

以上是我对V1.0版本CRM产品的设计过程介绍，由于篇幅原因就不再展开对每个功能细节的具体讨论。

六、总结与复盘

回顾整个项目，我认为收获到最多的是对产品全局把控的策略与思路。在产品规划初期，要对现在以及未来的业务发展趋势作出前瞻性预估，从而让系统架构更具扩展性；同时要学会平衡成本与产出，用最小的开发与人力成本完成当前最紧迫的业务问题，在不断地抉择与取舍中验证正确的方向前进。

本文由 @阿猫阿狗原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

降低软件复杂性的一般原则和方法

Tue, 24 Sep 2019 10:36:39 CST

一、前言

斯坦福教授、Tcl语言发明者John Ousterhout 的著作《A Philosophy of Software Design》[1]，自出版以来，好评如潮。按照IT图书出版的惯例，如果冠名为“实践”，书中内容关注的是某项技术的细节和技巧；冠名为“艺术”，内容可能是记录一件优秀作品的设计过程和经验；而冠名为“哲学"，则是一些通用的原则和方法论，这些原则方法论串起来，能够形成一个体系。正如”知行合一”、“世界是由原子构成的”、“我思故我在”，这些耳熟能详的句子能够一定程度上代表背后的人物和思想。用一句话概括《A Philosophy of Software Design》，软件设计的核心在于降低复杂性。

本篇文章是围绕着“降低复杂性”这个主题展开的，很多重要的结论来源于John Ousterhout，笔者觉得很有共鸣，就做了一些相关话题的延伸、补充了一些实例。虽说是"一般原则“，也不意味着是绝对的真理，整理出来，只是为了引发大家对软件设计的思考。

二、如何定义复杂性

关于复杂性，尚无统一的定义，从不同的角度可以给出不同的答案。可以用数量来度量，比如芯片集成的电子器件越多越复杂(不一定对)；按层次性[2]度量，复杂度在于层次的递归性和不可分解性。在信息论中，使用熵来度量信息的不确定性。

John Ousterhout选择从认知的负担和开发工作量的角度来定义软件的复杂性，并且给出了一个复杂度量公式：

子模块的复杂度cp乘以该模块对应的开发时间权重值tp，累加后得到系统的整体复杂度C。系统整体的复杂度并不简单等于所有子模块复杂度的累加，还要考虑该模块的开发维护所花费的时间在整体中的占比(对应权重值tp）。也就是说，即使某个模块非常复杂，如果很少使用或修改，也不会对系统的整体复杂度造成大的影响。

子模块的复杂度cp是一个经验值，它关注几个现象：

修改扩散，修改时有连锁反应。
认知负担，开发人员需要多长时间来理解功能模块。
不可知（Unknown Unknowns），开发人员在接到任务时，不知道从哪里入手。

造成复杂的原因一般是代码依赖和晦涩(Obscurity)。其中，依赖是指某部分代码不能被独立地修改和理解，必定会牵涉到其他代码。代码晦涩，是指从代码中难以找到重要信息。

三、解决复杂性的一般原则

首先，互联网行业的软件系统，很难一开始就做出完美的设计，通过一个个功能模块衍生迭代，系统才会逐步成型；对于现存的系统，也很难通过一个大动作，一劳永逸地解决所有问题。系统设计是需要持续投入的工作，通过细节的积累，最终得到一个完善的系统。因此，好的设计是日拱一卒的结果，在日常工作中要重视设计和细节的改进。

其次，专业化分工和代码复用促成了软件生产率的提升。比如硬件工程师、软件工程师（底层、应用、不同编程语言）可以在无需了解对方技术背景的情况下进行合作开发；同一领域服务可以支撑不同的上层应用逻辑等等。其背后的思想，无非是通过将系统分成若干个水平层、明确每一层的角色和分工，来降低单个层次的复杂性。同时，每个层次只要给相邻层提供一致的接口，可以用不同的方法实现，这就为软件重用提供了支持。分层是解决复杂性问题的重要原则。

第三，与分层类似，分模块是从垂直方向来分解系统。分模块最常见的应用场景，是如今广泛流行的微服务。分模块降低了单模块的复杂性，但是也会引入新的复杂性，例如模块与模块的交互，后面的章节会讨论这个问题。这里，我们将第三个原则确定为分模块。

最后，代码能够描述程序的工作流程和结果，却很难描述开发人员的思路，而注释和文档可以。此外，通过注释和文档，开发人员在不阅读实现代码的情况下，就可以理解程序的功能，注释间接促成了代码抽象。好的注释能够帮助解决软件复杂性问题，尤其是认知负担和不可知问题（Unknown Unknowns）。

四、解决复杂性之日拱一卒

4.1 拒绝战术编程

战术编程致力于完成任务，新增加特性或者修改Bug时，能解决问题就好。这种工作方式，会逐渐增加系统的复杂性。如果系统复杂到难以维护时，再去重构会花费大量的时间，很可能会影响新功能的迭代。

战略编程，是指重视设计并愿意投入时间，短时间内可能会降低工作效率，但是长期看，会增加系统的可维护性和迭代效率。

设计系统时，很难在开始阶段就面面俱到。好的设计应该体现在一个个小的模块上，修改bug时，也应该抱着设计新系统的心态，完工后让人感觉不到“修补”的痕迹。经过累积，最终形成一个完善的系统。从长期看，对于中大型的系统，将日常开发时间的10-15%用于设计是值得的。有一种观点认为，创业公司需要追求业务迭代速度和节省成本，可以容忍糟糕的设计，这是用错误的方法去追求正确的目标。降低开发成本最有效的方式是雇佣优秀的工程师，而不是在设计上做妥协。

4.2 设计两次

为一个类、模块或者系统的设计提供两套或更多方案，有利于我们找到最佳设计。以我们日常的技术方案设计为例，技术方案本质上需要回答两个问题，其一，为什么该方案可行？其二，在已有资源限制下，为什么该方案是最优的？为了回答第一个问题，我们需要在技术方案里补充架构图、接口设计和时间人力估算。而要回答第二个问题，需要我们在关键点或争议处提供二到三种方案，并给出建议方案，这样才有说服力。通常情况下，我们会花费很多的时间准备第一个问题，而忽略第二个问题。其实，回答好第二个问题很重要，大型软件的设计已经复杂到没人能够一次就想到最佳方案，一个仅仅“可行”的方案，可能会给系统增加额外的复杂性。对聪明人来说，接受这点更困难，因为他们习惯于“一次搞定问题”。但是聪明人迟早也会碰到自己的瓶颈，在低水平问题上徘徊，不如花费更多时间思考，去解决真正有挑战性的问题。

五、解决复杂性之分层

5.1 层次和抽象

软件系统由不同的层次组成，层次之间通过接口来交互。在严格分层的系统里，内部的层只对相邻的层次可见，这样就可以将一个复杂问题分解成增量步骤序列。由于每一层最多影响两层，也给维护带来了很大的便利。分层系统最有名的实例是TCP/IP网络模型。

在分层系统里，每一层应该具有不同的抽象。TCP/IP模型中，应用层的抽象是用户接口和交互；传输层的抽象是端口和应用之间的数据传输；网络层的抽象是基于IP的寻址和数据传输；链路层的抽象是适配和虚拟硬件设备。如果不同的层具有相同的抽象，可能存在层次边界不清晰的问题。

5.2 复杂性下沉

不应该让用户直面系统的复杂性，即便有额外的工作量，开发人员也应当尽量让用户使用更简单。如果一定要在某个层次处理复杂性，这个层次越低越好。举个例子，Thrift接口调用时，数据传输失败需要引入自动重试机制，重试的策略显然在Thrift内部封装更合适，开放给用户(下游开发人员）会增加额外的使用负担。与之类似的是系统里随处可见的配置参数(通常写在XML文件里），在编程中应当尽量避免这种情况，用户(下游开发人员)一般很难决定哪个参数是最优的，如果一定要开放参数配置，最好给定一个默认值。

复杂性下沉，并不是说把所有功能下移到一个层次，过犹不及。如果复杂性跟下层的功能相关，或者下移后，能大大下降其他层次或整体的复杂性，则下移。

5.3 异常处理

异常和错误处理是造成软件复杂的罪魁祸首之一。有些开发人员错误的认为处理和上报的错误越多越好，这会导致过度防御性的编程。如果开发人员捕获了异常并不知道如何处理，直接往上层扔，这就违背了封装原则。

降低复杂度的一个原则就是尽可能减少需要处理异常的可能性。而最佳实践就是确保错误终结，例如删除一个并不存在的文件，与其上报文件不存在的异常，不如什么都不做。确保文件不存在就好了，上层逻辑不但不会被影响，还会因为不需要处理额外的异常而变得简单。

六、解决复杂性之分模块

分模块是解决复杂性的重要方法。理想情况下，模块之间应该是相互隔离的，开发人员面对具体的任务，只需要接触和了解整个系统的一小部分，而无需了解或改动其他模块。

6.1 深模块和浅模块

深模块(Deep Module)指的是拥有强大功能和简单接口的模块。深模块是抽象的最佳实践，通过排除模块内部不重要的信息，让用户更容易理解和使用。

Unix操作系统文件I/O是典型的深模块，以Open函数为例，接口接受文件名为参数，返回文件描述符。但是这个接口的背后，是几百行的实现代码，用来处理文件存储、权限控制、并发控制、存储介质等等，这些对用户是不可见的。

  int open(const char* path, int flags, mode_t permissions);

与深模块相对的是浅模块(Shallow Module)，功能简单，接口复杂。通常情况下，浅模块无助于解决复杂性。因为他们提供的收益（功能）被学习和使用成本抵消了。以Java I/O为例，从I/O中读取对象时，需要同时创建三个对象FileInputStream、BufferedInputStream、ObjectInputStream，其中前两个创建后不会被直接使用，这就给开发人员造成了额外的负担。默认情况下，开发人员无需感知到BufferedInputStream，缓冲功能有助于改善文件I/O性能，是个很有用的特性，可以合并到文件I/O对象里。假如我们想放弃缓冲功能，文件I/O也可以设计成提供对应的定制选项。

  
FileInputStream fileStream = new FileInputStream(fileName);
BufferedInputStream bufferedStream = new BufferedInputStream(fileStream);
ObjectInputStream objectStream = new ObjectInputStream(bufferedStream);

关于浅模块有一些争议，大多数情况是因为浅模块是不得不接受的既定事实，而不见得是因为合理性。当然也有例外，比如领域驱动设计里的防腐层，系统在与外部系统对接时，会单独建立一个服务或模块去适配，用来保证原有系统技术栈的统一和稳定性。

6.2 通用和专用

设计新模块时，应该设计成通用模块还是专用模块？一种观点认为通用模块满足多种场景，在未来遇到预期外的需求时，可以节省时间。另外一种观点则认为，未来的需求很难预测，没必要引入用不到的特性，专用模块可以快速满足当前的需求，等有后续需求时再重构成通用的模块也不迟。

以上两种思路都有道理，实际操作的时候可以采用两种方式各自的优点，即在功能实现上满足当前的需求，便于快速实现；接口设计通用化，为未来留下余量。举个例子。

  
void backspace(Cursor cursor);
void delete(Cursor cursor);
void deleteSelection(Selection selection);

//以上三个函数可以合并为一个更通用的函数
void delete(Position start, Position end);

设计通用性接口需要权衡，既要满足当前的需求，同时在通用性方面不要过度设计。一些可供参考的标准：

满足当前需求最简单的接口是什么？在不减少功能的前提下，减少方法的数量，意味着接口的通用性提升了。
接口使用的场景有多少？如果接口只有一个特定的场景，可以将多个这样的接口合并成通用接口。
满足当前需求情况下，接口的易用性？如果接口很难使用，意味着我们可能过度设计了，需要拆分。

6.3 信息隐藏

信息隐藏是指，程序的设计思路以及内部逻辑应当包含在模块内部，对其他模块不可见。如果一个模块隐藏了很多信息，说明这个模块在提供很多功能的同时又简化了接口，符合前面提到的深模块理念。软件设计领域有个技巧，定义一个"大"类有助于实现信息隐藏。这里的“大”类指的是，如果要实现某功能，将该功能相关的信息都封装进一个类里面。

信息隐藏在降低复杂性方面主要有两个作用：一是简化模块接口，将模块功能以更简单、更抽象的方式表现出来，降低开发人员的认知负担；二是减少模块间的依赖，使得系统迭代更轻量。举个例子，如何从B+树中存取信息是一些数据库索引的核心功能，但是数据库开发人员将这些信息隐藏了起来，同时提供简单的对外交互接口，也就是SQL脚本，使得产品和运营同学也能很快地上手。并且，因为有足够的抽象，数据库可以在保持外部兼容的情况下，将索引切换到散列或其他数据结构。

与信息隐藏相对的是信息暴露，表现为：设计决策体现在多个模块，造成不同模块间的依赖。举个例子，两个类能处理同类型的文件。这种情况下，可以合并这两个类，或者提炼出一个新类（参考《重构》[3]一书）。工程师应当尽量减少外部模块需要的信息量。

6.4 拆分和合并

两个功能，应该放在一起还是分开？“不管黑猫白猫”，能降低复杂性就好。这里有一些可以借鉴的设计思路：

共享信息的模块应当合并，比如两个模块都依赖某个配置项。
可以简化接口时合并，这样可以避免客户同时调用多个模块来完成某个功能。
可以消除重复时合并，比如抽离重复的代码到一个单独的方法中。
通用代码和专用代码分离，如果模块的部分功能可以通用，建议和专用部分分离。举个例子，在实际的系统设计中，我们会将专用模块放在上层，通用模块放在下层以供复用。

七、解决复杂性之注释

注释可以记录开发人员的设计思路和程序功能，降低开发人员的认知负担和解决不可知(Unkown Unkowns)问题，让代码更容易维护。通常情况下，在程序的整个生命周期里，编码只占了少部分，大量时间花在了后续的维护上。有经验的工程师懂得这个道理，通常也会产出更高质量的注释和文档。

注释也可以作为系统设计的工具，如果只需要简单的注释就可以描述模块的设计思路和功能，说明这个模块的设计是良好的。另一方面，如果模块很难注释，说明模块没有好的抽象。

7.1 注释的误区

关于注释，很多开发者存在一些认识上的误区，也是造成大家不愿意写注释的原因。比如“好代码是自注释的"、"没有时间“、“现有的注释都没有用，为什么还要浪费时间”等等。这些观点是站不住脚的。“好代码是自注释的”只在某些场景下是合理的，比如为变量和方法选择合适的名称，可以不用单独注释。但是更多的情况，代码很难体现开发人员的设计思路。此外，如果用户只能通过读代码来理解模块的使用，说明代码里没有抽象。好的注释可以极大地提升系统的可维护性，获取长期的效率，不存在“没有时间”一说。注释也是一种可以习得的技能，一旦习得，就可以在后续的工作中应用，这就解决了“注释没有用”的问题。

7.2 使用注释提升系统可维护性

注释应当能提供代码之外额外的信息，重视What和Why，而不是代码是如何实现的(How)，最好不要简单地使用代码中出现过的单词。

根据抽象程度，注释可以分为低层注释和高层注释，低层次的注释用来增加精确度，补充完善程序的信息，比如变量的单位、控制条件的边界、值是否允许为空、是否需要释放资源等。高层次注释抛弃细节，只从整体上帮助读者理解代码的功能和结构。这种类型的注释更好维护，如果代码修改不影响整体的功能，注释就无需更新。在实际工作中，需要兼顾细节和抽象。低层注释拆散与对应的实现代码放在一起，高层注释一般用于描述接口。

注释先行，注释应该作为设计过程的一部分，写注释最好的时机是在开发的开始环节，这不仅会产生更好的文档，也会帮助产生好的设计，同时减少写文档带来的痛苦。开发人员推迟写注释的理由通常是：代码还在修改中，提前写注释到时候还得再改一遍。这样的话就会衍生两个问题：

首先，推迟注释通常意味着根本就没有注释。一旦决定推迟，很容易引发连锁反应，等到代码稳定后，也不会有注释这回事。这时候再想添加注释，就得专门抽出时间，客观条件可能不会允许这么做。
其次，就算我们足够自律抽出专门时间去写注释，注释的质量也不会很好。我们潜意识中觉得代码已经写完了，急于开展下一个项目，只是象征性地添加一些注释，无法准确复现当时的设计思路。

避免重复的注释。如果有重复注释，开发人员很难找到所有的注释去更新。解决方法是，可以找到醒目的地方存放注释文档，然后在代码处注明去查阅对应文档的地址。如果程序已经在外部文档中注释过了，不要在程序内部再注释了，添加注释的引用就可以了。

注释属于代码，而不是提交记录。一种错误的做法是将功能注释放在提交记录里，而不是放在对应代码文件里。因为开发人员通常不会去代码提交记录里去查看程序的功能描述，很不方便。

7.3 使用注释改善系统设计

良好的设计基础是提供好的抽象，在开始编码前编写注释，可以帮助我们提炼模块的核心要素：模块或对象中最重要的功能和属性。这个过程促进我们去思考，而不是简单地堆砌代码。另一方面，注释也能够帮助我们检查自己的模块设计是否合理，正如前文中提到，深模块提供简单的接口和强大的功能，如果接口注释冗长复杂，通常意味着接口也很复杂；注释简单，意味着接口也很简单。在设计的早期注意和解决这些问题，会为我们带来长期的收益。

八、后记

John Ousterhout累计写过25万行代码，是3个操作系统的重要贡献者，这些原则可以视为作者编程经验的总结。有经验的工程师看到这些观点会有共鸣，一些著作如《代码大全》、《领域驱动设计》也会有类似的观点。本文中提到的原则和方法具有一定实操和指导价值，对于很难有定论的问题，也可以在实践中去探索。

关于原则和方法论，既不必刻意拔高，也不要嗤之以鼻。指导实践的不是更多的实践，而是实践后的总结和思考。应用原则和方法论实质是借鉴已有的经验，可以减少我们自行摸索的时间。探索新的方法可以帮助我们适应新的场景，但是新方法本身需要经过时间检验。

九、参考文档

John Ousterhout. A Philosophy of Software Design. Yaknyam Press, 2018.
梅拉尼·米歇尔. 复杂. 湖南科学技术出版社, 2016.
Martin Fowler. Refactoring: Improving the Design of Existing Code (2nd Edition) . Addison-Wesley Signature Series, 2018.

作者介绍

政华，顺谱，陶鑫，美团打车调度系统工程团队工程师。

招聘信息

美团打车调度系统工程团队诚招高级工程师/技术专家，我们的目标，是与算法、数据团队密切协作，建设高性能、高可用、可配置的打车调度引擎, 为用户提供更好的出行体验。欢迎有兴趣的同学发送简历到tech@meituan.com（邮件标题注明：打车调度系统工程团队）。

可用性高达5个9！支付系统高可用架构设计实战

Wed, 12 Jun 2019 10:32:25 CST

一、背景

对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全不间断运行可以说“难于上青天”。为此，对应用可用性程度的衡量标准一般有3个9到5个9。

可用性指标	计算方式	不可用时间（分钟）
99.9%	0.1%36524*60	525.6
99.99%	0.01%36524*60	52.56
99.999%	0.001%36524*60	5.256

对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，宜信支付系统从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。

在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，宜信支付系统的服务能力可以达到99.999%。

本文重点讨论如何提高应用自身的可用性，关于如何避免单点故障和解决交易量增长问题会在其他系列讨论。

为了提高应用的可用性，首先要做的就是尽可能避免应用出现故障，但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方，任何一个看似很小的、发生概率为0的事故都可能出现，然后被无限放大。

大家都知道RabbitMQ本身是非常稳定可靠的，宜信支付系统最开始也一直在使用单点RabbitMQ，并且从未出现运行故障，所以大家在心理上都认为这个东西不太可能出问题。

直到某天，这台节点所在的物理主机硬件因为年久失修坏掉了，当时这台RabbitMQ就无法提供服务，导致系统服务瞬间不可用。

故障发生了也不可怕，最重要的是及时发现并解决故障。宜信支付系统对自身系统的要求是，秒级发现故障，快速诊断和解决故障，从而降低故障带来的负面影响。

二、问题

以史为鉴。首先我们简单的回顾一下，宜信支付系统曾经碰到的一些问题：

(1) 新来的开发同事在处理新接入的三方通道时，由于经验不足忽视了设置超时时间的重要性。就是这样一个小小的细节，导致这个三方队列所在的交易全部堵塞，同时影响到其他通道的交易；

(2) 宜信支付系统是分布式部署的，并且支持灰度发布，所以环境和部署模块非常多而且复杂。某次增加了一个新模块，由于存在多个环境，且每个环境都是双节点，新模块上线后导致数据库的连接数不够用，从而影响其他模块功能；

(3) 同样是超时问题，一个三方的超时，导致耗尽了当前所配置的所有worker threads, 以至于其他交易没有可处理的线程；

(4) A三方同时提供鉴权，支付等接口，其中一个接口因为宜信支付系统交易量突增，从而触发A三方在网络运营商那边的DDoS限制。通常机房的出口IP都是固定的，从而被网络运营商误认为是来自这个出口IP的交易是流量攻击，最终导致A三方鉴权和支付接口同时不可用。

(5) 再说一个数据库的问题，同样是因为宜信支付系统交易量突增引发的。建立序列的同事给某个序列的上限是999，999，999，但数据库存的这个字段长度是32位，当交易量小的时候，系统产生的值和字段32位是匹配的，序列不会升位。可是随着交易量的增加，序列不知不觉的升位数了，结果导致32位就不够存放。

类似这样的问题对于互联网系统非常常见，并且具有隐蔽性，所以如何避免就显得非常重要了。

三、解决方案

下面我们从三个方面来看宜信支付系统所做的改变。

3.1 尽可能避免故障

3.1.1 设计可容错的系统

比如重路由，对于用户支付来说，用户并不关心自己的钱具体是从哪个通道支付出去的，用户只关心成功与否。宜信支付系统连接30多个通道，有可能A通道支付不成功，这个时候就需要动态重路由到B或者C通道，这样就可以通过系统重路由避免用户支付失败，实现支付容错。

还有针对OOM做容错，像Tomcat一样。系统内存总有发生用尽的情况，如果一开始就对应用本身预留一些内存，当系统发生OOM的时候，就可以catch住这个异常，从而避免这次OOM。

3.1.2 某些环节快速失败“fail fast原则”

Fail fast原则是当主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，而不是等到出现负面影响才处理。

举个几个例子：

(1)支付系统启动的时候需要加载一些队列信息和配置信息到缓存，如果加载失败或者队列配置不正确，会造成请求处理过程的失败，对此最佳的处理方式是加载数据失败，JVM直接退出，避免后续启动不可用；

(2)支付系统的实时类交易处理响应时间最长是40s，如果超过40s前置系统就不再等待，释放线程，告知商户正在处理中，后续有处理结果会以通知的方式或者业务线主动查询的方式得到结果；

(3)宜信支付系统使用了redis做缓存数据库，用到的地方有实时报警埋点和验重等功能。如果连接redis超过50ms，那么这笔redis操作会自动放弃，在最坏的情况下这个操作带给支付的影响也就是50ms，控制在系统允许的范围内。

3.1.3 设计具备自我保护能力的系统

系统一般都有第三方依赖，比如数据库，三方接口等。系统开发的时候，需要对第三方保持怀疑，避免第三方出现问题时候的连锁反应，导致宕机。

（1）拆分消息队列

宜信支付系统提供各种各样的支付接口给商户，常用的就有快捷，个人网银，企业网银，退款，撤销，批量代付，批量代扣，单笔代付，单笔代扣，语音支付，余额查询，身份证鉴权，银行卡鉴权，卡密鉴权等。与其对应的支付通道有微信支付，ApplePay，支付宝等30多家支付通道，并且接入了几百家商户。在这三个维度下，如何确保不同业务、三方、商户、以及支付类型互不影响，宜信支付系统所做的就是拆分消息队列。下图是部分业务消息队列拆分图：

（2）限制资源的使用

对于资源使用的限制设计是高可用系统最重要的一点，也是容易被忽略的一点，资源相对有限，用的过多了，自然会导致应用宕机。为此宜信支付系统做了以下功课：

限制连接数

随着分布式的横向扩展，需要考虑数据库连接数，而不是无休止的最大化。数据库的连接数是有限制的，需要全局考量所有的模块，特别是横向扩展带来的增加。

限制内存的使用

内存使用过大，会导致频繁的GC和OOM，内存的使用主要来自以下两个方面：

A:集合容量过大；

B:未释放已经不再引用的对象，比如放入ThreadLocal的对象一直会等到线程退出的时候回收。

限制线程创建

线程的无限制创建，最终导致其不可控，特别是隐藏在代码中的创建线程方法。

当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换。Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换。

除此之外，Java应用在创建线程时会操作JVM堆外的物理内存，太多的线程也会使用过多的物理内存。

对于线程的创建，最好通过线程池来实现，避免线程过多产生上下文切换。

限制并发

做过支付系统的应该清楚，部分三方支付公司是对商户的并发有要求的。三方给开放几个并发是根据实际交易量来评估的，所以如果不控制并发，所有的交易都发给三方，那么三方只会回复“请降低提交频率”。

所以在系统设计阶段和代码review阶段都需要特别注意，将并发限制在三方允许的范围内。

我们讲到宜信支付系统为了实现系统的可用性做了三点改变，其一是尽可能避免故障，接下来讲后面两点。

3.2 及时发现故障

故障就像鬼子进村，来的猝不及防。当预防的防线被冲破，如何及时拉起第二道防线，发现故障保证可用性，这时候报警监控系统的开始发挥作用了。一辆没有仪表盘的汽车，是无法知道车速和油量，转向灯是否亮，就算“老司机”水平再高也是相当危险的。同样，系统也是需要监控的，最好是出现危险的时候提前报警，这样可以在故障真正引发风险前解决。

3.2.1 实时报警系统

如果没有实时报警，系统运行状态的不确定性会造成无法量化的灾难。宜信支付系统的监控系统指标如下：

实时性-实现秒级监控；
全面性-覆盖所有系统业务，确保无死角覆盖；
实用性-预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策；
多样性-预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题。

报警主要分为单机报警和集群报警，而宜信支付系统属于集群部署。实时预警主要依靠各个业务系统实时埋点数据统计分析实现，因此难度主要在数据埋点和分析系统上。

3.2.2 埋点数据

要做到实时分析，又不影响交易系统的响应时间，宜信支付系统在各个模块中通过redis实时做数据埋点，然后将埋点数据汇总到分析系统，分析系统根据规则进行分析报警。

3.2.3 分析系统

分析系统最难做的是业务报警点，例如哪些报警只要一出来就必须出警，哪些报警一出来只需要关注。下面我们对分析系统做一个详细介绍：

(1)系统运行架构

(2)系统运行流程

(3)系统业务监控点

宜信支付系统的业务监控点都是在日常运行过程中一点一滴总结出来的，分为出警类和关注类两大块。

A:出警类

网络异常预警；
单笔订单超时未完成预警；
实时交易成功率预警；
异常状态预警；
未回盘预警；
失败通知预警；
异常失败预警；
响应码频发预警；
核对不一致预警；
特殊状态预警；

B:关注类

交易量异常预警；
交易额超过500W预警；
短信回填超时预警；
非法IP预警；

3.2.4 非业务监控点

非业务监控点主要是指从运维角度的监控，包括网络，主机，存储，日志等。具体如下：

(1)服务可用性监控

使用JVM采集Young GC/Full GC次数及时间、堆内存、耗时Top 10线程堆栈等信息，包括缓存buffer的长度。

(2)流量监控

通过Agent监控代理部署在各个服务器上，实时采集流量情况。

(3)外部系统监控

通过间隙性探测来观察三方或者网络是否稳定。

(4)中间件监控

针对MQ消费队列，通过RabbitMQ脚本探测，实时分析队列深度；
针对数据库部分，通过安装插件xdb，实时监控数据库性能.

(5)实时日志监控

通过rsyslog完成分布式日志的归集，然后通过系统分析处理，完成日志实时监控和分析。最后，通过开发可视化页面展示给使用者。

(6)系统资源监控

通过Zabbix监控主机的CPU负载、内存使用率、各网卡的上下行流量、各磁盘读写速率、各磁盘读写次数(IOPS)、各磁盘空间使用率等。

以上就是宜信支付系统的实时监控系统所做的，主要分为业务点监控和运维监控两方面，虽然系统是分布式部署，但是每个预警点都是秒级响应。除此之外，业务系统的报警点也有一个难点，那就是有些报警是少量报出来不一定有问题，大量报警就会有问题，也就是所谓的量变引起质变。

举一个例子，拿网络异常来说，发生一笔可能是网络抖动，但是多笔发生就需要重视网络是否真的有问题，针对网络异常宜信支付系统的报警样例如下：

单通道网络异常预警：1分钟内A通道网络异常连续发生了12笔，触发了预警阀值；
多通道网络异常预警1: 10分钟内，连续每分钟内网络异常发生了3笔，涉及3个通道，触发了预警阀值；
多通道网络异常预警2： 10分钟内，总共发生网络异常25笔，涉及3个通道，触发了预警阀值.

3.2.5 日志记录和分析系统

对于一个大型系统而言，每天记录大量的日志和分析日志是有一定的难度的。宜信支付系统每天平均有200W笔订单量，一笔交易经过十几个模块流转，假设一笔订单记录30条日志，可想而知每天会有多么巨大的日志量。

宜信支付系统日志的分析有两个作用，一个是实时日志异常预警，另外一个是提供订单轨迹给运营人员使用。

(1)实时日志预警

实时日志预警是针对所有实时交易日志，实时抓取带有Exception或者Error的关键字然后报警。这样的好处是，如果代码中有任何运行异常，都会第一时间发现。宜信支付系统针对实时日志预警的处理方式是，首先采用rsyslog完成日志归集，然后通过分析系统实时抓取，再做实时预警。

(2)订单轨迹

对于交易系统，非常有必要实时了解一笔订单的状态流转。宜信支付系统最初的做法是通过数据库来记录订单轨迹，但是运行一段时间后，发现订单量剧增导致数据库表过大不利于维护。

宜信支付系统现在的做法是，每个模块通过打印日志轨迹，日志轨迹打印的格式按照数据库表结构的方式打印，打印好所有日志后，rsyslog来完成日志归集，分析系统会实时抓取打印的规范日志，进行解析然后按天存放到数据库中，并展示给运营人员可视化界面。

日志打印规范如下：

2016-07-22 18:15:00.512||pool-73-thread-4||通道适配器||通道适配器-发三方后||CEX16XXXXXXX5751||16201XXXX337||||||04||9000||【结算平台消息】处理中||0000105||98XX543210||GHT||03||11||2016-07-22 18:15:00.512||张张||||01||tunnelQuery||true||||Pending||||10.100.140.101||8cff785d-0d01-4ed4-b771-cb0b1faa7f95||10.999.140.101||O001||||0.01|||||||| http://10.100.444.59:8080/regression/notice||||240||2016-07-20 19:06:13.000xxxxxxx

||2016-07-22 18:15:00.170||2016-07-22 18:15:00.496xxxxxxxxxxxxxxxxxxxx

||2016-07-2019:06:13.000||||||||01||0103||111xxxxxxxxxxxxxxxxxxxxxxxxx

||8fb64154bbea060afec5cd2bb0c36a752be734f3e9424ba7xxxxxxxxxxxxxxxxxxxx

||622xxxxxxxxxxxxxxxx||9bc195a59dd35a47||f2ba5254f9e22914824881c242d211

||||||||||||||||||||6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx010||||||||||

简要日志可视化轨迹如下：

日志记录和分析系统除了以上两点，也提供了交易和响应报文的下载和查看。

3.2.6 7*24小时监控室

宜信支付系统以上的报警项目给操作人员提供推拉两种方式，一种是短信和邮件推送，一种是报表展示。除此之外，由于支付系统相比互联网其他系统本身的重要性，宜信支付系统采用7*24小时的监控室保证系统的安全稳定。

3.3 及时处理故障

在故障发生之后，特别是生产环境，第一时间要做的不是寻找故障发生的原因，而是以最快速度处理故障，保障系统的可用性。宜信支付系统常见的故障和处理措施如下：

3.3.1 自动修复

针对自动修复部分，宜信支付系统常见的故障都是三方不稳定造成的，针对这种情况，就是上面说的系统会自动进行重路由。

3.3.2 服务降级

服务降级指在出现故障的情况下又无法快速修复的情况下，把某些功能关闭，以保证核心功能的使用。宜信支付系统针对商户促销的时候，如果某个商户交易量过大，会实时的调整这个商户的流量，使此商户服务降级，从而不会影响到其他商户，类似这样的场景还有很多，具体的服务降级功能会在后续系列介绍。

四、Q&A

Q1: 能讲讲当年那台RabbitMQ宕掉的具体细节和处理方案吗？

A1: RabbitMQ宕机时间引发了对系统可用性的思考，当时我们的RabbitMQ本身并没有宕机（RabbitMQ还是很稳定的），宕机的是RabbitMQ所在的硬件机器，但是问题就出在当时RabbiMQ的部署是单点部署，并且大家惯性思维认为RabbitMQ不会宕机，从而忽略了它所在的容器，所以这个问题的产生对于我们的思考就是所有的业务不可以有单点，包括应用服务器、中间件、网络设备等。单点不仅仅需要从单点本身考虑，比如整个服务做双份，然后AB测试，当然也有双机房的。

Q2: 贵公司的开发运维是在一起的吗？

A2: 我们开发运维是分开的，今天的分享主要是站在整个系统可用性层面来考虑的，开发偏多，有一部分运维的东西。这些宜信支付系统的走过的路，是我一路见证过的。

Q3: 你们的后台全部使用的Java吗？有没有考虑其他语言？

A3: 我们目前系统多数是java，有少数的python、php、C++，这个取决于业务类型，目前java这个阶段最适合我们，可能随着业务的扩展，会考虑其他语言。

Q4: 对第三方依赖保持怀疑，能否举个具体的例子说明下怎么样做？万一第三方完全不了用了怎么办

A4: 系统一般都有第三方依赖，比如数据库，三方接口等。系统开发的时候，需要对第三方保持怀疑，避免第三方出现问题时候的连锁反应，导致宕机。大家都知道系统一旦发生问题都是滚雪球的，越来越大。比如说我们扫码通道，如果只有一家扫码通道，当这家扫码通道发生问题的时候是没有任何办法的，所以一开始就对它表示怀疑，通过接入多家通道，如果一旦发生异常，实时监控系统触发报警后就自动进行路由通道切换，保证服务的可用性；其二，针对不同的支付类型、商户、交易类型做异步消息拆分，确保如果一旦有一种类型的交易发生不可预估的异常后，从而不会影响到其他通道，这个就好比高速公路多车道一样，快车和慢车道互不影响。其实总体思路就是容错+拆分+隔离，这个具体问题具体对待。

Q5: 支付超时后，会出现网络问题，会不会存在钱已付，订单丢失，如何做容灾及数据一致性，又有没重放日志，修过数据？

A5：做支付最重要的就是安全，所以针对订单状态我们都是保守处理策略，因此对于网络异常的订单我们都是设置处理中状态，然后最终通过主动查询或者被动接受通知来完成和银行或者三方的最终一致性。支付系统中，除了订单状态还有响应码问题，大家都知道银行或者三方都是通过响应码来响应的，响应码和订单状态的翻译也是一定要保守策略，确保不会出现资金多付少付等问题。总之这个点的总体思路是，资金安全第一，所有的策略都是白名单原则。

Q6: 刚才提到过，若某支付通道超时，路由策略会分发至另一通道，根据那个通道图可看出，都是不同的支付方式，比如支付宝或微信支付，那如果我只想通过微信支付，为啥不是重试，而要换到另一通道呢？还是通道本身意思是请求节点？

A6：首先针对超时不可以做重路由，因为socket timeout是不能确定这笔交易是否发送到了三方，是否已经成功或者失败，如果是成功了，再重试一遍如果成功，针对付款就是多付，这种情况的资金损失对公司来说不可以的；其次，针对路由功能，需要分业务类型，如果是单笔代收付交易，用户是不关心钱是哪个通道出去的，是可以路由的，如果是扫码通道，用户如果用微信扫码，肯定最终是走微信，但是我们有好多中间渠道，微信是通过中间渠道出去的，这里我们可以路由不同的中间渠道，这样最终对于用户来说还是微信支付。

Q7: 能否举例说下自动修复的过程？如何发现不稳定到重路由的细节？

A7: 自动修复也就是通过重路由做容错处理，这个问题非常好，如果发现不稳定然后去决策重路由。重路由一定是明确当前被重路由的交易没有成功才可以路由，否则就会造成多付多收的资金问题。我们系统目前重路由主要是通过事后和事中两种方式来决策的，针对事后比如5分钟之内通过实时预警系统发现某个通道不稳定，那么就会把当期之后的交易路由到别的通道；针对事中的，主要是通过分析每笔订单返回的失败响应码，响应码做状态梳理，明确可以重发的才做重路由。这里我指列举这两点，其他的业务点还非常多，鉴于篇幅原因，不做详述，但是总体思路是必须有一个内存实时分析系统，秒级决策，这个系统必须快，然后结合实时分析和离线分析做决策支撑，我们的实时秒级预警系统就做这个事情。

Q8: 商户促销有规律吗？促销时峰值与平时相比会有多少差别？有技术演练么？降级的优先级是怎样的？

A8：商户促销一般我们会事先经常和商户保持沟通，事先了解促销的时间点和促销量，然后针对性做一些事情；促销峰值和平时差距非常大，促销一般都是2个小时之内的比较多，比如有的卖理财产品，促销也就集中在1个小时之内，所以峰值非常高；技术演练是我们在了解商户的促销量，然后预估系统的处理能力，然后提前做演练；降级的优先级主要是针对商户的，由于接入我们的商户支付场景比较多的，有理财，有代收付，有快捷，有扫码等等，所以我们整体原则就是不同的商户之间一定不可以相互影响，因为不能因为你家做促销影响了其他商家。

Q9：rsyslog归集日志怎么存储的？

A9: 这个是好问题，刚开始我们的日志也就是订单轨迹log是记录在数据库表中的，结果发现一笔订单流转需要好多模块，这样一笔订单的日志轨迹就是10笔左右，如果一天400w笔交易的话，这张数据库表就有问题了，就算拆分也是会影响数据库性能的，并且这个属于辅助业务，不应该这样做。然后，我们发现写日志比写数据库好，所以把实时日志打印成表格的形式，打印到硬盘上，这块由于只是实时日志所以日志量不大，就是在日志服务器的一个固定目录下。由于日志都是在分布式机器上，然后通过归集日志到一个集中的地方，这块是通过挂载存储的，然后有专门运维团队写的程序去实时解析这些表格形式的日志，最终通过可视化页面展示到运营操作页面，这样运营人员看到的订单轨迹几乎是实时的，您关心的怎么存储实际上不是啥问题，因为我们分了实时日志和离线日志，然后超过一定时间的离线日志会切割，最终被删除。

Q10: 系统监控和性能监控如何配合的？

A10：我理解的系统监控包括了系统性能监控，系统性能监控是系统整体监控的一部分，不存在配合问题，系统性能监控有多个维度，比如应用层面，中间件，容器等。系统的非业务监控可以查看文章分享。

作者：冯忠旗

来源：宜信技术学院

错误信息提示在表单中的最佳位置

Sat, 01 Jun 2019 17:18:49 CST

在你的表单设计中，你会把错误信息提示放在哪个位置呢？如果它们不符合用户预期，就可能成为用户体验上的障碍。试想，当用户输入错误的信息时，他们首先需要理解错误是什么，然后才是修正错误、重新提交表单。但如果这个过程太费劲，他们可能就会选择放弃继续填写。

表单上方的有效性 VS 内部的有效性

最常见的错误信息提示放置位置是表单的上方或内部，那么哪个位置对用户来说体验更好呢？有研究发现，在表单上方显示错误信息提示，会对用户的记忆产生负担。当填写错误时，错误信息提示在最上方容易让用户在改正信息的时候要去回忆，到底是哪里填错了，怎样才能填正确。而把错误信息提示放在表单内部可以减少用户的记忆负担，用户主要依赖于即时识别而非回忆，所以会更快更简单地改正错误。另一个研究发现，“输入错误和错误信息提示的距离影响错误修正的效率”。把错误信息放在表单顶部或者底部，会导致用户修改错误所需的时间最长，而内联形式的错误信息提示所需要修改的时间是最短的。同时，将错误信息放在表单顶部或者底部在用户侧，错误率最高、修改时间最长，用户满意度也最低。其中，与顶部和内联相比，底部的提示具有最低的纠错成功率。

错误信息提示位置的用户偏好

研究证明，内联形式的错误提示可以得到最佳的用户体验，同时这项研究还给上下左右四个方向排了优先级（如下图）。参与这项研究的用户，对他们最满意的信息提示位置进行了评级，显示出了强烈的用户偏好。放置在左侧的错误消息被评为最差，在上方的被认为难以记忆，下方的被认为比较难记。

输入框右侧是最佳区域

理解为什么放在右侧能够符合用户习惯与期望是重要的。通过这种方式，设计师可以做出体验更好的产品。西方的阅读习惯是从左到右。当用户视线从输入到错误反馈，这是一个非常自然的过程，不需要动脑。从看到错误信息提示到输入改正错误，也需要遵循阅读习惯。

输入框左侧是最差区域

把错误信息提示放在左侧区域，违背了西方的阅读习惯。当错误信息提示出现的时候，用户的视觉动线需要朝着阅读习惯的反方向移动。这会让用户感觉到不自然，而且这会违反直觉，因为用户预期高优先级的元素应该是在左侧。把错误信息提示放在左侧让人感觉比输入项更重要。但是输入内容显然是更重要的，因为用户需要聚焦在输入框上，修正他们的输入。

输入框的上方增加识别负担

当错误信息提示放在输入框的上方，而表格上方有标签项的时候，用户会经历更高的认知负担。这是因为错误信息提示和标签混在一起，很容易让用户产生疑惑。根据临近原则，当用户尝试去阅读错误信息提示或标签的时候，这两个文本会产生视觉混乱，所以结果是难以聚焦而让用户分心。

错误信息提示在移动端表单的最佳位置

手机屏幕缺少横向空间去展示输入框两侧的错误信息提示，这就意味着放在右侧的错误信息提示对于手机端表单来说不是最好的位置。正确的处理方式是把错误信息提示放在输入框下方，这是用户第二偏好的位置。尽管这不符合用户的从左到右的自然阅读流程，但符合从上到下的阅读顺序。当用户阅读文本时，他们的视线是从左到右、从上到下地看。错误信息提示在输入框的下方是符合垂直的阅读顺序的。需要注意的是，把错误信息放在输入框下方时，不要与表单项目标题靠的太近，会容易形成干扰。

输入框的右侧 VS 输入框的下方：哪个是最佳位置？

输入框的右侧或下方都是错误信息提示的最佳位置。选哪个位置取决于你需要做多少工作。如果你想节省时间，桌面端和手机端设同一套的话，选下方位置。如果你有时间和资源为两端做不同的设计，那手机端选下方，桌面端选右侧，这个方案可帮助缩短用户在电脑端的视觉路径。

直觉的错误信息提示位置

总结一下， 错误信息提示的位置应该和用户的阅读流程保持一致，这样错误改正用到的成本最少。当减少用户操作和思考的时间精力，用户就能更快完成表格。没有人喜欢填写表单，因此，帮助用户更快地填写表单，产品的体验才能变得更好。原文：https://medium.com/@uxmovement/the-best-place-for-error-messages-on-forms-6e9e84740be8 作者：UX Movement 译者：胡白白 (公众号：彩云译设计 id:caiyunyisheji)

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

电商营销工具之优惠券设计思路分析

Fri, 17 May 2019 16:28:37 CST

本文结合实际经验，与大家分享一下优惠券相关产品的设计思路，一起来看看~

又到了一年618，现在的你是不是已经在各大电商平台开始囤积各种优惠券，什么满减券、折扣券、整点券等，先不管券到底能干嘛，先统统领了再说。于是手机各种定时抢券，等到购物的时候发现，领的券99%都不能用，不是商品不符合就是券已过期。

面对这样的情况，本文结合之前的电商产品活动经验，把优惠券相关产品的设计思路跟大家分享下，希望对各位能有所帮助。

一、明确优惠券活动的目的及意义

优惠券随处可见，基本你知道的行业，都有优惠券的存在，通过发放优惠券，让用户在下单的时候抵扣一定的费用，达到促销的目的。优惠券另一个用处就是合理的提高客单价，从而提高产品的销售利润。

但很多人都不把优惠券当回事，觉得发出去没多少人会使用。但凡抱着这种想法的人，都不是好运营，首先要明白优惠券并不是交易工具，而是一种运营策略。

对活动来说，优惠券是订单转化和拉升客单价的有力工具对品牌来说，优惠券是用户维护乃至用户召回的重要手段。

那么优惠券到底有哪些种类，他们常见的使用场景都是在什么样的呢？

优惠方式：满减券、代金券、折扣券、通用券；
适用范围： 单品券、品类券、店铺券。

总体来说，各个优惠券的具体使用条件及适用范围如下：

目前优惠券玩法里面，因为折扣券的成本核算较为复杂，且无法对用户造成直接的价格冲击，因此用的较少，玩的比较多的是满减券、代金券。

满减券：有一定的使用条件，要满足一定的订单金额才能使用，例如满300-30这种玩法；
代金券：相对条件要简单点，虽然也是满足一定金额才能使用，但额度要求低，常见的就是50-5/100-10这两种形式。

二、优惠券常见的六种发放形式

（1）主动发券

主动发券顾名思义，是商家主动给用户发券。

线上的玩法通常是新人注册礼包、用户福利活动等，承载形式可以是小游戏、品牌宣传等，用户输入账号即可领取，线下一般就是优惠传单。

（2）消费返券

消费返券指的是在用户消费后发券，主要目的是实现二次复购，通常的形式都是满100减X元。

这个玩法也比较多，通常都是直接给纸质优惠券，或者可以邀请用户扫公众号，输入特定关键词领取优惠券链接，也可以是邀请用户参加抽奖活动，设定不同的优惠券档次随机抽取

（3）分享发券

这是目前使用最多的发券玩法，用户在获得红包时需分享后打开领取。最常见的有邀请送红包、外卖红包等，既可以回馈下单用户福利。又可以促活老用户，还可以实现拉新目的。

（4）积分兑券

这是属于用户体系的一部分，通过在积分商城兑换的方式，一方面可以让用户获取福利，同时还能通过消耗积分的方式，让用户为了获取积分再次活跃。

积分的获取来源方式也很多，比如：公众号打卡签到、积分宝任务获取积分等。

（5）任务发券

这是最简单的一种发券方式，用户完成特定任务/活动/游戏后即可获得优惠券。

比如：春节知识问答活动，通过回答春节小问题，根据回答程度领取不同的优惠券

（6）异业发券

这种不属于任何发券玩法，完全是通过异业合作的形式达到目的。

例如：选择与自家目标用户有重叠的平台合作，在该平台发券导流该平台用户到自家平台，实现换量拉新。

以上这些玩法，都可以通过人人秀这种第三方营销平台，将优惠券植入各种营销活动中，例如：抽奖、抽红包、打卡积分兑换、集福等多种营销模式，一方面可以提升粉丝的黏性，同时也可以借助优惠券唤醒部分沉睡用户，实现二次销售转化。

三、优惠券的常见推广渠道

除了做好优惠券本身的活动设置外，最重要的就是如何发放优惠券，很多人以为基于概率论的结果，肯定是发的越多转化越多。

但优惠券绝对不是阳光普照奖，遍地可得的优惠券没人会在意，就像很多新店开业会发优惠传单，可大多数人拿了就扔了，反而是吃饭的时候领的优惠券会一直留着。

这时候就要去探寻优惠券的本质核心，究竟什么样的优惠券是吸引人，什么样的优惠券是会刺激用户用券并付费购物。

首先大家要知道， 优惠券不单单是一种促销工具，更是一种“价格歧视”策略。

举个例子：

物品A成本5元，定价10元时，有100人购买；定价15元时，有60人会购买。

前者利润为500元，后者利润为600元，但我如果使用了5元优惠券去吸引未购买的40人，则利润一共是800元。

从这个例子里就可以看到，对于活动运营来说，优惠券的力度及定价会影响销售转化；对于用户运营而言，优惠券会对不同体系用户进行黏性维护。

因此，优惠券不是一个价格问题，他的本质是心理学问题！所有的优惠券的发放，都是要给到用户一种占便宜的心理和良好的感受，因为用户要的不是占你三块五块的便宜，是享受这种占便宜的优越感。

那么优惠券常见的发放渠道跟发放形式有哪些呢？通常来说有以下几种：

（1）去中心化，社会化传播

优惠卷与其他营销方式的一个很大的区别是，它可以做到脱离电商产品进行独立传播，结合微信购物商城的实际情况，可以将其做成优惠卷链接，在微信用户中传播。

（2）活动娱乐化，游戏化传播

这种形式常见天猫双11、京东618活动中，例如：参加某某游戏，结束后可以随机领取优惠券。

（3）营销精准化，集中投放给价格敏感用户

这种需要有较为完善的客户资源库，已经对客户进行了标签管理，对于那些更看重价格的用户，通过微信定向推送等一系列精准营销的方式，激活唤醒这部分用户。

四、优惠券的八大设计要素

我们会看到，用户之所以愿意使用优惠券，是因为通过使用优惠券，他可以在购物过程中减少实际的资金支付金额，也就是少花钱。

所以我们需要考虑如何让用户了解到全部的信息，也就是用户可以通过什么渠道了解有优惠券可用、如何获取优惠券、购买的商品是否达到用券额度等等，这就需要我们做好各个关键环节的用户体验，让用户的购物过程更加顺畅，同时也要更有利于我们的销售转化。

既然要让用户有一种占便宜的感觉，那就需要对优惠券进行一定的设计，让用户在使用的时候可以抵扣费用。

优惠券的种类虽然五花八门，但核心玩法就两种：

直接抵扣固定金额
在订单价格上打折

这是优惠券的八大要素，其中最核心的是优惠力度。因为优惠力度会直接影响转化，如果力度过大则利润总体变薄，如果力度过小则用户不感兴趣。

所以我们要做的就是找到用户能承担的最高支付价格，但会存在这样的一个问题，东西如果你定价为50元，并没有哪个用户会告诉你，

这个定价低了，我其实能接受75元，这就需要我们分别从不同角度去思考。

另外为了保证业绩，做优惠券发放的时候，一定要考虑到优惠券的时效性和有限性。

时效性：指的是要设置优惠券的使用时间，建议一般为3-5天，如果是通用券可以设置为1个月。
有限性：指限定活动可以优惠的金额，同时限定优惠券的每日发放数量，另外可以针对不同人群进行投放，保证覆盖全整个用户。

五、如何利用优惠券实现业绩突破

为了冲业绩，在不亏本的前提下优惠力度要尽量大，最大化刺激用户购买下单。

为了提升客单价，需要制定阶段性价格策略，比如现在客单价是50元，则可以制定满70元减20元的优惠券。

为了维护用户粘性，针对已有的会员用户体系，可以对不同等级的用户发放不同优惠券，VIP1享受满20减5元优惠券，VIP2享受满30减10元优惠券，VIP3享受满50减20元优惠券，以此类推。

为了刺激用户留存使用，需要针对潜在流失人群发放优惠券，最常见的就是支付宝红包，支付宝红包的逻辑就是，长时间未使用支付宝的用户红包金额，会大于高活跃用户，这也是防止用户流失的一个手段。

六、如何做好优惠券数据统计分析

当我们设计好优惠券，并完成了一定渠道的投放后，我们需要对优惠券的结果做好数据统计。

一般的数学模型通常是： 渠道推广量>用户领取量>实际使用量

我们看这三个中间的转化就可以分析出来结果，简单来说：

推广量到领取量的转化，代表的是优惠券对用户的吸引力如何，主要侧重渠道的有效性和领取页面的好坏。
领取量到使用量的转化，说明的是优惠券的下单吸引力，主要侧重说明运营的价格策略提醒是否有效。

结语

其实优惠券活动并不简单，它涉及到经济学、心理学等多方面问题，也是运营人需要掌握的重要运营策略，尤其是不同行业的运营，更需要针对自身行业钻研优惠券的玩法。

本文由 @人人秀原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

HTTP API 认证授权术

Thu, 09 May 2019 21:37:29 CST

我们知道，HTTP是无状态的，所以，当我们需要获得用户是否在登录的状态时，我们需要检查用户的登录状态，一般来说，用户的登录成功后，服务器会发一个登录凭证（又被叫作Token），就像你去访问某个公司，在前台被认证过合法后，这个公司的前台会给你的一个访客卡一样，之后，你在这个公司内去到哪都用这个访客卡来开门，而不再校验你是哪一个人。在计算机的世界里，这个登录凭证的相关数据会放在两种地方，一个地方在用户端，以Cookie的方式（一般不会放在浏览器的Local Storage，因为这很容易出现登录凭证被XSS攻击），另一个地方是放在服务器端，又叫Session的方式（SessonID存于Cookie）。

但是，这个世界还是比较复杂的，除了用户访问，还有用户委托的第三方的应用，还有企业和企业间的调用，这里，我想把业内常用的一些 API认证技术相对系统地总结归纳一下，这样可以让大家更为全面的了解这些技术。 注意，这是一篇长文！

本篇文章会覆盖如下技术：

HTTP Basic
Digest Access
App Secret Key + HMAC
JWT – JSON Web Tokens
OAuth 1.0 – 3 legged & 2 legged
OAuth 2.0 – Authentication Code & Client Credential

HTTP Basic

HTTP Basic 是一个非常传统的API认证技术，也是一个比较简单的技术。这个技术也就是使用 username和 password 来进行登录。整个过程被定义在了 RFC 2617 中，也被描述在了 Wikipedia: Basic Access Authentication 词条中，同时也可以参看 MDN HTTP Authentication

其技术原理如下：

把 username和 password 做成 username:password 的样子（用冒号分隔）
进行Base64编码。 Base64("username:password") 得到一个字符串（如：把 haoel:coolshell 进行base64 后可以得到 aGFvZW86Y29vbHNoZWxsCg ）
把 aGFvZW86Y29vbHNoZWxsCg放到HTTP头中 Authorization 字段中，形成 Authorization: Basic aGFvZW86Y29vbHNoZWxsCg，然后发送到服务端。
服务端如果没有在头里看到认证字段，则返回401错，以及一个个 WWW-Authenticate: Basic Realm='HelloWorld' 之类的头要求客户端进行认证。之后如果没有认证通过，则返回一个401错。如果服务端认证通过，那么会返回200。

我们可以看到，使用Base64的目的无非就是为了把一些特殊的字符给搞掉，这样就可以放在HTTP协议里传输了。而这种方式的问题最大的问题就是把用户名和口令放在网络上传，所以，一般要配合TLS/SSL的安全加密方式来使用。我们可以看到 JIRA Cloud 的API认证支持HTTP Basic 这样的方式。

但我们还是要知道，这种把用户名和密码同时放在公网上传输的方式有点不太好，因为Base64不是加密协议，保是编码协议，所以就算是有HTTPS作为安全保护，给人的感觉还是不放心。

Digest Access

中文称“HTTP 摘要认证”，最初被定义在了 RFC 2069 文档中（后来被 RFC 2617 引入了一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数）。

其基本思路是，请求方把用户名口令和域做一个MD5 – MD5(username:realm:password) 然后传给服务器，这样就不会在网上传用户名和口令了，但是，因为用户名和口令基本不会变，所以，这个MD5的字符串也是比较固定的，因此，这个认证过程在其中加入了两个事，一个是 nonce 另一个是 qop

首先，调用方发起一个普通的HTTP请求。比如： GET /coolshell/admin/ HTTP/1.1
服务端自然不能认证能过，服务端返回401错误，并且在HTTP头里的 WWW-Authenticate 包含如下信息：

 WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"

其中的 nonce 为服务器端生成的随机数，然后，客户端做 HASH1=MD5(MD5(username:realm:password):nonce:cnonce) ，其中的 cnonce 为客户端生成的随机数，这样就可以使得整个MD5的结果是不一样的。
如果 qop 中包含了 auth ，那么还得做 HASH2=MD5(method:digestURI) 其中的 method 就是HTTP的请求方法（GET/POST…）， digestURI 是请求的URL。
如果 qop 中包含了 auth-init ，那么，得做 HASH2=MD5(method:digestURI:MD5(entityBody)) 其中的 entityBody 就是HTTP请求的整个数据体。
然后，得到 response = MD5(HASH1:nonce:nonceCount:cnonce:qop:HASH2) 如果没有 qop则 response = MD5(HA1:nonce:HA2)
最后，我们的客户端对服务端发起如下请求—— 注意HTTP头的 Authorization: Digest ...

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="%2Fcoolshell%2Fadmin",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

维基百科上的 Wikipedia: Digest access authentication 词条非常详细地描述了这个细节。

摘要认证这个方式会比之前的方式要好一些，因为没有在网上传递用户的密码，而只是把密码的MD5传送过去，相对会比较安全，而且，其并不需要是否TLS/SSL的安全链接。但是，别看这个算法这么复杂，最后你可以发现，整个过程其实关键是用户的password，这个password如果不够得杂，其实是可以被暴力破解的，而且，整个过程是非常容易受到中间人攻击——比如一个中间人告诉客户端需要一个。

App Secret Key + HMAC

先说HMAC技术，这个东西来自于MAC – Message Authentication Code，是一种用于给消息签名的技术，也就是说，我们怕消息在传递的过程中被人修改，所以，我们需要用对消息进行一个MAC算法，得到一个摘要字串，然后，接收方得到消息后，进行同样的计算，然后比较这个MAC字符串，如果一致，则表明没有被修改过（整个过程参看下图）。而HMAC – Hash-based Authenticsation Code，指的是利用Hash技术完成这一工作，比如：SHA-256算法。

（图片来自 Wikipedia – MAC 词条）

我们再来说App ID，这个东西跟验证没有关系，只是用来区分，是谁来调用API的，就像我们每个人的身份证一样，只是用来标注不同的人，不是用来做身份认证的。与前面的不同之处是，这里，我们需要用App ID 来映射一个用于加密的密钥，这样一来，我们就可以在服务器端进行相关的管理，我们可以生成若干个密钥对（AppID, AppSecret），并可以有更细粒度的操作权限管理。

把AppID和HMAC用于API认证，目前来说，玩得最好最专业的应该是AWS了，我们可以通过 S3的API请求签名文档看到AWS是怎么玩的。整个过程还是非常复杂的，可以通过下面的图片流程看个大概。基本上来说，分成如下几个步骤：

把HTTP的请求（方法、URI、查询字串、头、签名头，body）打个包叫 CanonicalRequest，作个SHA-256的签名，然后再做一个base16的编码
把上面的这个签名和签名算法 AWS4-HMAC-SHA256、时间戳、Scop，再打一个包，叫 StringToSign。
准备签名，用 AWSSecretAccessKey来对日期签一个 DataKey，再用 DataKey 对要操作的Region签一个 DataRegionKey ，再对相关的服务签一个 DataRegionServiceKey ，最后得到 SigningKey.
用第三步的 SigningKey来对第二步的 StringToSign 签名。

最后，发出HTTP Request时，在HTTP头的 Authorization字段中放入如下的信息：

Authorization: AWS4-HMAC-SHA256 
               Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, 
               SignedHeaders=content-type;host;x-amz-date, 
               Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7

其中的 AKIDEXAMPLE 是 AWS Access Key ID，也就是所谓的 AppID，服务器端会根据这个AppID来查相关的 Secret Access Key，然后再验证签名。如果，你对这个过程有点没看懂的话，你可以读一读这篇文章——《 Amazon S3 Rest API with curl》这篇文章里有好些代码，代码应该是最有细节也是最准确的了。

这种认证的方式好处在于，AppID和AppSecretKey，是由服务器的系统开出的，所以，是可以被管理的，AWS的IAM就是相关的管理，其管理了用户、权限和其对应的AppID和AppSecretKey。但是不好的地方在于，这个东西没有标准，所以，各家的实现很不一致。比如： Acquia 的 HMAC，微信的签名算法（这里，我们需要说明一下，微信的API没有遵循HTTP协议的标准，把认证信息放在HTTP 头的 Authorization 里，而是放在body里）

JWT – JSON Web Tokens

JWT是一个比较标准的认证解决方案，这个技术在Java圈里应该用的是非常普遍的。JWT签名也是一种MAC（ Message Authentication Code）的方法。JWT的签名流程一般是下面这个样子：

用户使用用户名和口令到认证服务器上请求认证。
认证服务器验证用户名和口令后，以服务器端生成JWT Token，这个token的生成过程如下：
- 认证服务器还会生成一个 Secret Key（密钥）
- 对JWT Header和 JWT Payload分别求Base64。在Payload可能包括了用户的抽象ID和的过期时间。
- 用密钥对JWT签名 HMAC-SHA256(SecertKey, Base64UrlEncode(JWT-Header)+'.'+Base64UrlEncode(JWT-Payload));
然后把 base64(header).base64(payload).signature 作为 JWT token返回客户端。
客户端使用JWT Token向应用服务器发送相关的请求。这个JWT Token就像一个临时用户权证一样。

当应用服务器收到请求后：

应用服务会检查 JWT Token，确认签名是正确的。
然而，因为只有认证服务器有这个用户的Secret Key（密钥），所以，应用服务器得把JWT Token传给认证服务器。
认证服务器通过JWT Payload 解出用户的抽象ID，然后通过抽象ID查到登录时生成的Secret Key，然后再来检查一下签名。
认证服务器检查通过后，应用服务就可以认为这是合法请求了。

我们可以看以，上面的这个过程，是在认证服务器上为用户动态生成 Secret Key的，应用服务在验签的时候，需要到认证服务器上去签，这个过程增加了一些网络调用，所以，JWT除了支持HMAC-SHA256的算法外，还支持RSA的非对称加密的算法。

使用RSA非对称算法，在认证服务器这边放一个私钥，在应用服务器那边放一个公钥，认证服务器使用私钥加密，应用服务器使用公钥解密，这样一来，就不需要应用服务器向认证服务器请求了，但是，RSA是一个很慢的算法，所以，虽然你省了网络调用，但是却费了CPU，尤其是Header和Payload比较长的时候。所以，一种比较好的玩法是，如果我们把header 和 payload简单地做SHA256，这会很快，然后，我们用RSA加密这个SHA256出来的字符串，这样一来，RSA算法就比较快了，而我们也做到了使用RSA签名的目的。

最后，我们只需要使用一个机制在认证服务器和应用服务器之间定期地换一下公钥私钥对就好了。

这里强烈建议全文阅读 Anglar 大学的《 JSW：The Complete Guide to JSON Web Tokens》

OAuth 1.0

OAuth也是一个API认证的协议，这个协议最初在2006年由Twitter的工程师在开发OpenID实现的时候和社交书签网站Ma.gnolia时发现，没有一种好的委托授权协议，后来在2007年成立了一个OAuth小组，知道这个消息后，Google员工也加入进来，并完善有善了这个协议，在2007年底发布草案，过一年后，在2008年将OAuth放进了IETF作进一步的标准化工作，最后在2010年4月，正式发布OAuth 1.0，即： RFC 5849 （这个RFC比起TCP的那些来说读起来还是很轻松的），不过，如果你想了解其前身的草案，可以读一下 OAuth Core 1.0 Revision A ，我在下面做个大概的描述。

根据RFC 5849，可以看到 OAuth 的出现，目的是为了，用户为了想使用一个第三方的网络打印服务来打印他在某网站上的照片，但是，用户不想把自己的用户名和口令交给那个第三方的网络打印服务，但又想让那个第三方的网络打印服务来访问自己的照片，为了解决这个授权的问题，OAuth这个协议就出来了。

这个协议有三个角色：
- User（照片所有者-用户）
- Consumer（第三方照片打印服务）
- Service Provider（照片存储服务）
这个协义有三个阶段：
- Consumer获取Request Token
- Service Provider 认证用户并授权Consumer
- Consumer获取Access Token调用API访问用户的照片

整个授权过程是这样的：

Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
当 User 访问 Consumer 时，Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（ oauth_token）和 Request Token Secret （ oauth_token_secret）
Consumer 收到 Request Token 后，使用HTTP GET 请求把 User 切到 Service Provide 的认证页上（其中带上Request Token），让用户输入他的用户和口令。
Service Provider 认证 User 成功后，跳回 Consumer，并返回 Request Token （ oauth_token）和 Verification Code（ oauth_verifier）
接下来就是签名请求，用Request Token 和 Verification Code 换取 Access Token （ oauth_token）和 Access Token Secret ( oauth_token_secret)
最后使用Access Token 访问用户授权访问的资源。

下图附上一个Yahoo!的流程图可以看到整个过程的相关细节。

因为上面这个流程有三方：User，Consumer 和 Service Provide，所以，又叫 3-legged flow，三脚流程。OAuth 1.0 也有不需要用户参与的，只有Consumer 和 Service Provider 的，也就是 2-legged flow 两脚流程，其中省掉了用户认证的事。整个过程如下所示：

Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（ oauth_token）和 Request Token Secret （ oauth_token_secret）
Consumer 收到 Request Token 后，直接换取 Access Token （ oauth_token）和 Access Token Secret ( oauth_token_secret)
最后使用Access Token 访问用户授权访问的资源。

最后，再来说一说OAuth中的签名。

我们可以看到，有两个密钥，一个是Consumer注册Service Provider时由Provider颁发的 Consumer Secret，另一个是 Token Secret。
签名密钥就是由这两具密钥拼接而成的，其中用 &作连接符。假设 Consumer Secret 为 j49sk3j29djd 而 Token Secret 为 dh893hdasih9那个，签名密钥为： j49sk3j29djd&dh893hdasih9
在请求Request/Access Token的时候需要对整个HTTP请求进行签名（使用HMAC-SHA1和HMAC-RSA1签名算法），请求头中需要包括一些OAuth需要的字段，如：
- Consumer Key ：也就是所谓的AppID
- Token： Request Token 或 Access Token
- Signature Method ：签名算法比如：HMAC-SHA1
- Timestamp：过期时间
- Nonce：随机字符串
- Call Back：回调URL

下图是整个签名的示意图：

图片还是比较直观的，我就不多解释了。

OAuth 2.0

在前面，我们可以看到，从Digest Access，到AppID+HMAC，再到JWT，再到OAuth 1.0，这些个API认证都是要向Client发一个密钥（或是用密码）然后用HASH或是RSA来签HTTP的请求， 这其中有个主要的原因是，以前的HTTP是明文传输，所以，在传输过程中很容易被篡改，于是才搞出来一套的安全签名机制，所以，这些个认证的玩法是可以在HTTP明文协议下玩的。

这种使用签名方式大家可以看到是比较复杂的，所以，对于开发者来说，也是很不友好的，在组织签名的那些HTTP报文的时候，各种，URLEncode和Base64，还要对Query的参数进行排序，然后有的方法还要层层签名，非常容易出错，另外，这种认证的安全粒度比较粗，授权也比较单一，对于有终端用户参与的移动端来说也有点不够。所以，在2012年的时候，OAuth 2.0 的 RFC 6749 正式放出。

OAuth 2.0依赖于TLS/SSL的链路加密技术（HTTPS），完全放弃了签名的方式，认证服务器再也不返回什么 token secret 的密钥了，所以，OAuth 2.0是完全不同于1.0 的，也是不兼容的。目前，Facebook 的 Graph API 只支持OAuth 2.0协议，Google 和 Microsoft Azure 也支持Auth 2.0，国内的微信和支付宝也支持使用OAuth 2.0。

下面，我们来重点看一下OAuth 2.0的两个主要的Flow：

一个是Authorization Code Flow，这个是 3 legged 的
一个是Client Credential Flow，这个是 2 legged 的。

Authorization Code Flow

Authorization Code 是最常使用的OAuth 2.0的授权许可类型，它适用于用户给第三方应用授权访问自己信息的场景。这个Flow也是OAuth 2.0四个Flow中我个人觉得最完整的一个Flow，其流程图如下所示。

下面是对这个流程的一个细节上的解释：

1）当用户（Resource Owner）访问第三方应用（Client）的时候，第三方应用会把用户带到认证服务器（Authorization Server）上去，主要请求的是 /authorize API，其中的请求方式如下所示。

https://login.authorization-server.com/authorize?
        client_id=6731de76-14a6-49ae-97bc-6eba6914391e
        &response_type=code
        &redirect_uri=http%3A%2F%2Fexample-client.com%2Fcallback%2F
        &scope=read
        &state=xcoiv98CoolShell3kch

其中：

- client_id为第三方应用的App ID
- response_type=code为告诉认证服务器，我要走Authorization Code Flow。
- redirect_uri意思是我跳转回第三方应用的URL
- scope意是相关的权限
- state 是一个随机的字符串，主要用于防CSRF攻击。

2）当Authorization Server收到这个URL请求后，其会通过 client_id来检查 redirect_uri和 scope是否合法，如果合法，则弹出一个页面，让用户授权（如果用户没有登录，则先让用户登录，登录完成后，出现授权访问页面）。

3）当用户授权同意访问以后，Authorization Server 会跳转回 Client ，并以其中加入一个 Authorization Code。如下所示：

https://example-client.com/callback?
        code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
        &state=xcoiv98CoolShell3kch

我们可以看到，

- 请流动的链接是第 1）步中的 redirect_uri
- 其中的 state 的值也和第 1）步的 state一样。

4）接下来，Client 就可以使用 Authorization Code 获得 Access Token。其需要向 Authorization Server 发出如下请求。

POST /oauth/token HTTP/1.1
Host: authorization-server.com
 
code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
&grant_type=code
&redirect_uri=https%3A%2F%2Fexample-client.com%2Fcallback%2F
&client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&client_secret=JqQX2PNo9bpM0uEihUPzyrh

5）如果没什么问题，Authorization 会返回如下信息。

{
  "access_token": "iJKV1QiLCJhbGciOiJSUzI1NiI",
  "refresh_token": "1KaPlrEqdFSBzjqfTGAMxZGU",
  "token_type": "bearer",
  "expires": 3600,
  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciO.eyJhdWQiOiIyZDRkM..."
}

其中，

- access_token就是访问请求令牌了
- refresh_token用于刷新 access_token
- id_token 是JWT的token，其中一般会包含用户的OpenID

6）接下来就是用 Access Token 请求用户的资源了。

GET /v1/user/pictures
Host: https://example.resource.com

Authorization: Bearer iJKV1QiLCJhbGciOiJSUzI1NiI

Client Credential Flow

Client Credential 是一个简化版的API认证，主要是用于认证服务器到服务器的调用，也就是没有用户参与的的认证流程。下面是相关的流程图。

这个过程非常简单，本质上就是Client用自己的 client_id和 client_secret向Authorization Server 要一个 Access Token，然后使用Access Token访问相关的资源。

请求示例

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=czZCaGRSa3F0Mzpn
&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

返回示例

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

这里，容我多扯一句，微信公从平台的开发文档中，使用了OAuth 2.0 的 Client Credentials的方式（参看文档“ 微信公众号获取access token”），我截了个图如下所谓。我们可以看到，微信公众号使用的是GET方式的请求，把AppID和AppSecret放在了URL中，虽然这也符合OAuth 2.0，但是并不好，因为大多数网关代理会把整个URI请求记到日志中。我们只要脑补一下腾讯的网关的Access Log，里面的日志一定会有很多的各个用户的AppID和AppSecret……

小结

讲了这么多，我们来小结一下（下面的小结可能会有点散）

两个概念和三个术语

区分两个概念：Authentication（认证）和 Authorization （授权），前者是证明请求者是身份，就像身份证一样，后者是为了获得权限。身份是区别于别人的证明，而权限是证明自己的特权。Authentication为了证明操作的这个人就是他本人，需要提供密码、短信验证码，甚至人脸识别。Authorization 则是不需要在所有的请求都需要验人，是在经过Authorization后得到一个Token，这就是Authorization。就像护照和签证一样。
区分三个概念：编码Base64Encode、签名HMAC、加密RSA。编码是为了更的传输，等同于明文，签名是为了信息不能被篡改，加密是为了不让别人看到是什么信息。

明白一些初衷

使用复杂地HMAC哈希签名方式主要是应对当年没有TLS/SSL加密链路的情况。
JWT把 uid 放在 Token中目的是为了去掉状态，但不能让用户修改，所以需要签名。
OAuth 1.0区分了两个事，一个是第三方的Client，一个是真正的用户，其先拿Request Token，再换Access Token的方法主要是为了把第三方应用和用户区分开来。
用户的Password是用户自己设置的，复杂度不可控，服务端颁发的Serect会很复杂，但主要目的是为了容易管理，可以随时注销掉。
OAuth 协议有比所有认证协议有更为灵活完善的配置，如果使用AppID/AppSecret签名的方式，又需要做到可以有不同的权限和可以随时注销，那么你得开发一个像AWS的IAM这样的账号和密钥对管理的系统。