Oct 10, 2018
阻塞
#
阻塞(bio)指cpu等待io
非阻塞(nio)指调用io后立即返回，但要轮询事件状态
# 非阻塞指对cpu不阻塞，但业务线程阻塞
轮询(单线程)
read
定时重复调用来检查
select
前后read, 中间select轮询检查文件描述符的事件状态
采用1024长度数组存储状态，只能同时检查1024个文件描述符
poll
前后read, 中间poll
用链表代替数组, 也避免了不必要的检查
epoll # linux
前后read, 中间epoll
epoll检查不到事件，休眠epoll线程直到事件将它唤醒
kqueue # freeBSD中，类似epoll
aio # async io, linux, 业务线程不阻塞
通过回调(信号)传递数据，不必像epoll线程(业务线程)阻塞等待
仅linux下有, 只O_DIRECT方式读取，不能利用系统缓存
IOCP # windows aio
模拟aio(io线程池)
业务线程的io操作, 起io线程, io线程完成通信到业务线程触发回调
库
glibc(有bug)
libeio
node.js的libuv封装
linux下自实现
windows下IOCP
事件
#
实现
回调
队列存事件, 单进程检测事件是否回调
库
libevent
libev # bug比libevent少
工具
epoll(select, poll)
libev(libevent)
并发并行
#
并发
多任务共享时间段, 类比: 任务队列
为什么并发
多任务能力
非阻塞
并行
多任务同时处理, 类比: 多核处理器
为什么并行
提高执行效率
分类
任务并行化
数据并行化
cpu交替任务 # EDSAC串行任务
协作式 # 可能独占，Windows3.1, Mac OS 9
抢占式 # 任务管理器强制中断，Windows95, Mac OS 9以后版本, Unix, Linux
竞态条件
三条件
两个处理共享变量
一个修改中
另一个介入
没有共享
Multics(1969年)进程共享内存 # Multics基于PL/I和汇编编写
UNICS(1970年)进程不共享内存
UNIX10年后，线程共享进程内存
actor模型(1973年), 不共享内存，传递消息，异步 # Erlang, Scala
共享内存但不修改 # haskell所有变量，c++ const变量, scala val变量, java immutable(private属性没有setter)
不介入修改
线程协作式 # ruby的Fibre, python/js的generator
不便介入标志
锁(有线程不检查锁，还是可以进入) # 1965年提出，1974年改良为monitor。加解锁时，要求对锁的检查和修改同时执行
死锁问题
无法组合锁，组合要加新锁
事务内存 # 临时创建版本对其修改，更新失败重新执行
硬件事务内存(1986年硬件安装lisp的LM-2) # 1986年cpu MIPS基于RISC简化指令成功，LM-2商业失败
软件事务内存(1995年论文), 2005年微软concurrent haskell论文
2004年IBM X10, 2006年Sun Fortress, 2007年Clojure, 2010年微软终止.NET软件事务内存
并行代码
编译代码顺序不确定，或执行顺序不确定
看一句代码的内部实现, 在其中执行了行为
go func () { x = make([]int, 10) }()
x[9] = 1
业务并行解耦条件(满足幺半群性质)
封闭性 # 业务运算结果是业务
结合律 # 业务a、b的结果后与c执行，等同b、c的结果与a执行
单位元 # 恒等业务a与其它业务b执行，得b, 如reduce的初值
系统应用
并发能力
吞吐量(并行)
I/O多路复用(epoll)
cpu"多路复用"(进程、线程)
cpu机制(多发射、流水线、超标量、超线程)
进程线程应用
cpu对任务的M:N处理
进程切换处理任务
线程(通信，并行)
实现(异步, 并发，并行)
写法
回调(监听器), 链式(promise)，同步(async)
事件处理器
调度方式: 单线程循环
协程
为什么用户实现协程
POSIX线程模型累赘
进程/线程 切换开销大
空间资源占用大
os调度对go模型不合理
go gc需要内存处理一致状态(所有线程停止), os调度时，因gc时间不确定，期间大量线程停止工作
# go调度器知道什么时候内存处于一致性状态(只需正在核上运行线程)
本质
用户态，寄存器+栈, 让出(协作而非抢占)
调度方式(线程模型)
N:1 # N个用户空间线程运行在1个内核空间线程
上下文切换快
无法利用多核
1:1
# POSIX(pthread), java
利用多核
上下文切换慢，每次调度都在用户态和内核态间切换
M:N
任意内核模型管理任意goroutine
调度复杂性大
go
M(machine)代表内核线程
G(goroutine)有自己的栈，程序计数器，调度信息(如正阻塞的channel)
P(processor)调度上下文, $GOMAXPROCS设置数量
P中有G队列(runqueue, 队尾添加新G)
当前运行一个G, 到调度点时，队列弹出另一个G
P周期检查全局G队列防止其中G饿死
P运行完，全局G队列拉取G
P运行完，全局G队列空，从其它P拉取一半G
P运行在M, M阻塞时P移到其它M, 阻塞M中保留阻塞的G
调度器创建足够多M跑P
阻塞M中G的syscall返回, M尝试偷一个P
没得到P时, 它的G加入全局G队列, M进线池睡眠
概念
过度竞争
过多线程尝试同时使用一个共享资源
同步 # 直接相互制约
实现
同步原语(如通道、锁)作用时，会刷处理器缓存到内存并提交，保证可见性
互斥 # 间接相互制约
竞态条件(race condition)
临界区 # 只能一线程访问的代码，如lock了的代码
监控模式 # 互斥锁, 函数, 变量 组合出临界区的模式, 使用了代理人(broker)(指锁)
异步
# 与同步相对。多线程是实现异步的一种手段
可见性
线程总可见到最后修改的数据, 脏读是反例
原子性
查看和修改同时发生
乱序执行
# java 中标记volatile的变量可以不乱序执行, 现多用原子变量
编译器或JVM的静态优化可以打乱代码执行顺序(java)
硬件可以通过乱序执行来优化性
死锁 # 多线程竞争资源而互相等待
条件
互斥 # 资源排他
不剥夺 # 资源不被外力剥夺
请求和保持条件 # 线程已保持一个资源，请求新资源。请求被阻塞而自己资源保持
循环等待 # 阻塞线程形成环
方案
锁按顺序获得 # a,b,c锁，要得c手中要有a, b
# 使用锁的地方比较零散时，遵守此顺序变得不实际
# 可以用对象散列值作全局顺序减小死锁机率
阻塞加时限
# 外星方法中可能包含另一把锁，要避免在持锁时调用外星方法
活锁 # 多线程尝试绕开死锁而过分同步反复冲突
多线程
#
线程池
作用
重复利用, 降低资源消耗
提高响应速度，不等线程创建
可管理，线程是稀缺资源，统一分配，调优和监控，提高系统稳定性
锁
公平锁 # FIFO取锁
非公平锁 # 每次直接占有
互斥锁(mutex) # 访问前加锁，访问后解锁
悲观锁 # 假设最坏，等所有线程释放成功
读加锁
乐观锁 # 假设最好，有冲突时重试
读不加锁，写时判断数据版本是否修改，再重试
读写锁(rwlock) # 竞争不激烈比互斥锁慢
读锁(共享锁)
写锁(互斥锁)
状态
读加锁状态
可多个线程占用
处理器缓存提交，数据可见
阻塞写线程 # 导致写线程抢占不到资源，所以有写线程时，阻塞后进入的读线程
写加锁状态
一次只有一个线程占用
阻塞所有线程
不加锁状态
自旋锁 spinlock
互斥锁改，自己进入循环等待状态(忙等) # 适合锁持有时间较短
RCU锁 Read-Copy Update
读写锁改，一个写线程，读线程无限制
实现垃圾回收器
写线程copy副本修改，向垃圾回收器注册callback以执行真正的修改
垃圾回收器收到信号，所有读线程结束，执行callback
可重入锁 # 互斥锁改，允许同一线程多次获得写锁
管程(monitor)
临界区(critical section)
内置锁、显示锁 # 指java的synchronized与Reentrantlock
信号量
进程, 线程间通知状态
CAS
#
# compare and swap，无锁算法(lock free), 非阻塞(non-blocking), 构成基本的乐观锁
# cpu实现的指令
3个操作数
# V的值为A时，原子更新成B，否则无操作。返回V的值
需要读写的内存位置V
进行比较的值A
拟写入的新值B
函数式
#
介绍
消除可变状态
概念
命令式语言中，求值顺序与源码的语句顺序紧密相关(有可能乱序执行)
函数式程序并不描述"如何求值以得到结果"，而是描述"结果应当是什么样的"。函数式编程中，如何安排求值顺序相对自由
引用透明性
# 任何调用函数的地方，都可以用函数运行结果来替换函数调用，而不会产生副作用
数据流式编程(dataflow programming)
# (+ (+ 1 2) (+ 3 4))就是一个数据流，所有函数都可以用时执行
future模型
分离标识与状态
#
介绍
Clojure, 指令式编程和函数式编程混搭
clojure四种并发模型
vars (thread-local)
atoms原子变量
agent代理
refs引用 与 ATM软件事务内存
actor模型
#
介绍
作为actor自己修改自己的数据，对外提供消息，处理对外消息
共享内存模型和分布式内存模型，适合解决地理分布型问题，强大的容错性
基于消息传递，侧重通道两端实体
每个actor有一个mailbox, mailbox中转消息
csp
#
介绍
通信顺序进程(communicating sequential processes)
基于消息传递，侧重信息通道
数据级并行
#
# 不可变数据, 观测不可变、实现不可变
lambda架构
#
介绍
综合MapReduce和流式处理的特点，处理大数据问题的架构
状态保持
#
cookie
分域名, 客户端保存服务器定义数据, 请求时发送
session
服务器id数据，id下发到客户端
共享
# 同时多方案，动态切换 zookeeper切换环境变量与重启
# java中filter重写request getSession
webSphere或JBoss可配置session复制或共享
# 不好扩展和移植
加密存cookie
服务
redis
memorycache
gemfire # 12306
认证
#
单点登录
sessionID存cookie, cookie禁用存头域
token
类型
access token
# 标识唯一用户
user_id
issue_time
# token发放时间，单位秒
ttl
# 有效时间，uint16,单位分钟
mask
# int128, 按bit分组用户，用于批量封禁或其它功能
refresh token
# 用来换access token，与access token同时发放
# 过期时间更长
实现
redis存储
token不要太长
常见问题
#
CSRF
#
介绍
跨域请求伪造(cross-site request forgery)
client登录A, 本地生成cookie
client登录B, B给执行js，带参数请求站点A
解决
token验证 # 加入自定义头域
验证Referer头域
XSS
#
介绍
跨站脚本攻击(cross-site scripting, 易和css混淆，所以写成XSS), 渲染页面时脚本未转义
XSF
#
介绍
跨站flash攻击(cross-site flash), actionScript加载第三方flash
sql注入
#
介绍
拼装sql，参数插入sql逻辑
解决
sql预编译
1+N查询
#
介绍
先查出外键id集合, 再逐条id查关联表。orm易出的问题
解决
用 id IN (1,2,3)
commit前自动合并sql
业务场景
#
关注/信箱
#
要求
user人数10w, 活跃1w。
大部分user关注1k人, 一部分大v被关注100w人。
每人每天发100条博文
user新博文数量提醒，消息标记已读
表
user
user_followers
user_followed
user_posts(u_id, created_ts)
user_messages(u_id, p_id, is_read)
# 10w * 100条数据 / 天
定时任务拉取
user_followed拉u_id, user_posts表按时段拉id, 更新user_messages
优点
平均, 少次, 增量。
缺点
及时性中
每次对所有用户操作
数据
10w*1k*100条数据 / 天
发布时推送
有p_id, user_followers, 更新user_messages
优点
及时性高
缺点
计算集中, 可能高峰
数据
最高 100w*100条数据 / 次
10w*100次 / 天
messages处理
存部分messages
不活跃user不存message
在登录状态，定时拉取
优点
减少message
缺点
计算集中
数据
1k * N(N<100)条 / 次
1w * 1k * 100条数据 / 天
messages结构变化
u_id: [{p_id: uint, is_read: bool}] # 条数稳定为10w
用mongodb或redis
消息队列?
服务端存message状态，不能mq
如果客户端存状态，这就是个简单的mq问题
轻应用架构
#
node.js + mongodb
mysql
数据
#
数据迁移
#
去掉约束
排序（中断继续）
数据存储
#
缓存
queue + map
# queue存储、限量, map查询，指向queue中元素
缓存
#
queue + map
# queue存储、限量, map查询，指向queue中元素
实时并发
#
异步方案
#
node.js + mongodb
tornado + celery + rabbitmq + 优先级
quartz
消息
#
功能
好友
单聊, 群聊
语音, 视频
im # 浏览器聊天(tcp, 不https)
协议
XMPP # 基于xml
MQTT # 简单，但自己实现好友、群组
SIP # 复杂
私有协议 # 工作量大，扩展性差
go高并发实时消息推送
#
问题
长连接 # 支持多种协议(http、tcp)
server push
HTTP long polling(keep-alive)
基于TCP自定义
心跳侦测
高并发 #>= 10,000,000
C1000K
多种发送方式
单播: 点对点聊天
多播: 定点推送
广播: 全网推送
持久/非持久
准实时 # 200ms ~ 2s
gc卡顿是大问题
客户端多样性
同帐号多端接入
网络变化
电信、联通切换
wifi, 4g, 3g
断线、重连、断线、重连
系统架构
组件
room
# 接入客户端
分布式全对称
一个client一个goroutine
每个server一个channel存消息队列
book记录user与server映射
统一http server收消息并将消息路由到room和server
manager掌控room的服务：内部单播、多播、广播
admin负责room进程管理
center
# 运营人员从后台接入
提供操纵接口给应用服务器调用
restful
长时操作，有任务概念来管理
提供统计接口
register
# room和center注册
key-value的map，value是struct
记录用户连到哪个room
记录在线时长等信息
hash算法定位register进程
不直接用redis是为了添加业务逻辑
saver
# room和center调用
# 使用redis
分布式全对称
提供存储接口
采用encoding/gob编码格式的rpc
idgenerator
# saver和center调用
全局消息id生成器, int64
分布式，每个进程负责一块id区域
后台goroutine每隔一秒写一次磁盘，记录当前id
启动时跳过一段id，防止一秒内未写入磁盘的id重复生成
存储
redis
存核心数据
db_users: zset, 存各产品用户集合
db_slots: list, 存用户离线消息队列
db_buckets: dict, 存消息id -> 消息体
数据
16机器，标配24硬件线程, 64g内存
linux kernel 2.6.32 x86_64
单机80万并发连接
load 0.2 ~ 0.4 cpu
总使用率7%~10%
内存占用20g
目前接入1280万在线用户
2分钟一次gc, 停顿2秒，tip上提供了并行gc
15亿个心跳包/天
持续运行一个月无异常
直播
#
《关于直播，所有的技术细节都在这里了》
游戏
#
进程
gateway进程组
# 对外api
function进程组
# 注册玩家全局信息
session进程组
# 玩家状态
dbserver进程组
# 数据
多word进程组
# 不同地图的信息、逻辑
Oct 10, 2018
Presentation
#
指导思想: 成于结构，臻于对话
PPT画页
画的是冰山一角
类似手持卡片
类似左右脑: 逻辑+展示
具体内容
思维导图
维度筛选，MECE不重不漏
空姐现象
共知的事情特色讲，去掉已知部分
卖钻讲孔
电梯法则
告知全局，步骤清晰，回顾小结
递进逻辑：信息，分析，方法
目录
首页效应
目录，章节页，总结页
视觉
图形代替文字: 缩小了看一看
标题附主题语: 有兴趣有信息量
讲
替画重点（提示语如: 请注意，提问）
细讲：页只写观点，串联起来讲，只有30%内容重合
心态
注意力放在观众那边
沟通合作而非防御
房间有更聪明的人
数字化转型
#
什么是数字化，有什么用
发展
信息化: 烟囱式，信息/数据孤岛，管理/运营孤岛
互联网化
互联互通: 0边际成本互联互通，云计算->雾计算
大数据化
数据互联: 互联一切->一切互联，跨界应用
数据资源: 核心要素/资产，第一权利
数智化
人工智能：大数据->大知识, 人类设计->自动学习，替代与超越
计算智能->感知智能->认知智能
三位一体：(互联网+大数据+人工智能)+ Any
数字孪生、元宇宙
互联网+
信息传递边际成本趋向于0
连接机制革命
任意两个资源(人或物)0边际成本互联互通: 信息0边际成本
传播机制: 线性、金字塔式->非线性、网状、几何级、病毒式
带来什么
数字科技三位一体：(互联网+大数据+人工智能)+
边际革命：0边际成本效应，边际成本递减，边际收益递增
数智：可知、可达、可控、可预测，程度剧变、实现边际成本剧变
量变->质变（工具革命->革命的工具）
局部改善->全面优化->全面重构
技术应用->业务优化->全面变革
农业时代，工业时代，数字时代，造物时代
为什么数字化转型
企业处境
各行各业先后
总量短缺->结构过剩，卖方市场->买方市场，存量经济的争夺内卷加剧
成熟稳定期->跃迁剧变期
各行各业被迫转型：不断重新分工、重新分利
产业链 重构/(替代+重构)
战略问题
不是未来做什么，是做什么有未来
提高打鱼技术但鱼没有了
不要战术勤奋战略懒惰, 战术成功战略失败
不是选择题是必答题
什么是企业/产业数字化
IBA+经济
电子商贸，流通
不是虚拟经济，是实体经济的全新形态
IBA+交易
渠道体系革命
线上渠道为主，主导线上线下一体化
终端(触点)为王
与用户空间时间距离不断缩短
一切皆终端，终端多样化->场景碎片化(场景嵌入)->新旧场景兴衰
泛在智能交互，泛在智能感应(不断向生产环节渗透)
交易边际成本大幅下降, 交易可能性边界急剧膨胀，资源配置能力与利用效率极大提高
产业链重构：M2B2C, M2C, P2P
野蛮营销->精准营销->智能匹配
产品变渠道，产品渠道一体化
智能产品->触点+服务与生态体系
产品成为持续服务的载体
制造业服务业化
智能化，机器体系对人的脑力及体力的强助力、替代、超越
精细化、高度集成化
去人化、极致自动化
柔性化，按需生产、柔性制造能力
IBA+生产
业务跨界与跃迁：供应链资源，数据资源，新“物种”(产品)
低碳、低能耗、低消耗: 自然资源稀缺性下降
IBA+交易+生产
交易生产一体化
由需到供，按需生产，按需服务，按需研发，按需投资，0库存
非标->标准化->去标准化(个性化生产)
卖产品->卖生产服务，制造业服务业化
延展到整个国民经济生态体系，有计划的市场经济
数据驱动，智能决策
平台化+极致专业化分工
企业(管理与产权)形态、雇佣形态的演变
管控型->交易型/平台型
企业人员规模缩小，企业边界模糊
企业、资本与劳动者关系演变
数字化转型
数字经济质跃工业经济
数字经济系统
经济环境: 人类经济活动(分工协作)的基础条件(信息不对称性，资源稀缺性)发生剧变
经济活动: 交易和生产的边际成本大幅下降，经济活动的效率大幅上升，经济活动的可能性边界急剧膨胀
从根本上超越工业经济
数字化经济含义
交易、生产：0边际成本
边际革命：人类逐步进入0边际成本时代
边际成本递减->0边际成本->边际成本为负
结果变成原因，逼近转型升级
数字化转型升级
以数字科技为应用手段，持续推进业务变革、组织变革
经济的数字化转型升级: 以数字科技应用为手段，推进经济模式、经济形态持续转型升级
企业数字化转型升级：以数字科技应用为手段，推进企业营销模式、服务模式、管理模式、生产模式、决策模式、商业模式、产权模式等持续转型升级
鸿沟：科技<->业务
可能性(无限)->现实性(有限)
科技->技术应用(产品/模式/制度创新变革)->业务问题->科技应用创新不足是制约转型升级、创新发展的关键瓶颈
问题导向，需求拉动
科技应用价值问题：经济效益是检验科技领先的唯一标准
科技应用方向问题：0到0的创新比0到1的创新更关键
科技应用的路径问题：并非都是"富家子""优等生"
转型是什么
三个层次
新赛道(局部): 新技术、新产品、新兴产业链
新形态(普遍): 新业态、新模式、新型产业链
新经济(全面): 新生态、新格局
企业：全面转型或K型经济
可行方法
你是谁：业务现状
你想变成谁
动因与目标(短期、长期)
问题导向与需求分析
你能变成谁
基础条件与既有资源
信息化数字化的基础
你如何变成谁
(周而复始)设计->建设->运营(业务+系统)->跟踪与评估
得客户资源者得天下
流量->留量
客户资源：客户数据+客户关系+客户渠道
以更低边际成本掌控更大的客户资源
谁掌握完备的客户资源
如何掌握完备的客户资源
未来已临
划时代的技术都是试金石
与时代赛跑
实施
本质
数字驱动的用户中心观, 不是业务中心观
增长三角：规模、分工、效率
思维: 大数据、区块链
用户价值:
一个框架: 价值创造，用户挖掘，用户数据，个性化服务，差异化用户保留
一个目标: 每个用户"精耕细作"
一个重点: 数字化全链路管理，全场景营销, 全渠道服务
价值网络: 一个核心
商业模式
Costco"复利高墙"
差异化价值、服务对象、盈利模式+核心能力
数字化会员：精准预测，精准选品，自有品牌
供应链
问题：牛鞭效应，不确定效应
解决：基于数据观察趋势，不预测趋势
增长飞轮
数字化加速技术分层分化, 技术模块化
运营卓越: 上游核心技术，下游用户亲密
数智化转型
#
技术：人工智能，区块链，云计算，大数据，边缘计算
管理：科学管理->人本管理->精益管理->价值共生
重塑思维
战略转型方向
管理变革
商业模式
重塑领导力
数字化营销
#
4P: 产品、价格、渠道、推广
4C： 消费者(Consumer)、成本(Cost)、便利(Convenience)、沟通(Communication)
4R: 关联(Relevance), 反应(Reacton), 关系(Relationship), 报酬(Reward)
Marketing Jungle: 及时性、社会性、精准性、方便性
CIDR
Contact: 全渠道(全场景): 在商，在家，在途
Identify: 二维码，小程序，人脸，Beacon
Data: 数据标签(分级分群)
Reaction
大数据营销
3V: 数量(Volume)、速率(Velocity)、多样(Variety)
维度
身份象征: 年龄、身高、性别、居住地
生活风格: 朝九晚五、泡吧达人、工作狂
消费行为: 购买时间、购买方式、促销敏感
社交行为：意见领袖、意见跟随者
商品偏好：咖啡达人、面包达人
RFM: 最近消费、消费频率、消费金额
升级：金字塔(二八原则)
挽留
精准营销：相关分析、逻辑回归分析、购物栏分析、标签群体聚类分析
私域
进(获客)
线下：自然来客、地推
会员裂变
大数据：探针法、数据交换法、WiFi法
产品为王
线上引流：SEO, SEM/关键字投放, ASO, CPS(按销售付费), DSP(跨平台), Banner, 嵌入代码/挂件，微信/社交/短视频
活(激活)
不删: 电子会员、交互平台、创造场景
关卡：产生兴趣、激发欲望、消除顾虑(七天免费)、立刻行动
粘(粘性)
RFM分群
R: 最近一次消费
F: 消费频次
M: 消费金额
增加粘性: 次数带动，品类带动，场景带动
值(客户价值)
CLV=贡献价值 - (取得成本+维系成本)
荐(裂变)
原因: 创造价值 获客
方法
分享, 红包，IP,亲子，团购, 朋友
移动营销
优势：实时在线、高效传递、多媒体负载、瞬间反应
特色4I: 个性化(I)、互动(Interactive)、分众识别(Individual Identification)、实时信息(Instant Message)
设备：二维码、App、小程序、穿戴技术
MAC Address: 基地台，路径
Beason: 室内
DSP: 标签种植
限制：隐私侵犯、推送用APP未打开、设备更换
七个瞬间
场景: 时间地点，和谁一起，当前感觉，需要什么; 和上次一样
位置距离: 地理定位，地理围栏，地理征地
时间
实用性产品(效率): 早上
享乐型产品(心情): 下午
天气
影响心情
预防性框架
轨迹
社会: 和谁一起
拥挤度
社交媒体
pay media, earned media, owned media
社群
粉丝: 目的
企业：目的
方式
找兴趣, 嬴关注
造品牌, 聚粉丝
场景思维
围绕产品
围绕时间
围绕特定事件
内容营销
步骤
任务规划：对象、目的、场景
阶段性目标：粉丝数、活跃度、互动数、观看数、展示数、流量数据
内容创意：起承转合, story board
标题、价值(有趣、有利)、为什么转发(显示一手信息、表达立场、自娱娱人)
确定渠道: 对象，内容类型，流量机制
评估学习
内容策略
热点性内容
即时性内容
生活故事内容
方案或学习性(生活小贴士)
连载性内容
促销性内容
全流程整合
交易平台: 微商、微店(企业内店、第三方平台)、微商城
分润机制: 入会条件、会员等级、推荐提成、等级折扣
企业管理
#
战略
目标：使命，愿景
分层
企业层面战略
业务单元层面战略（竞争战略）
职能层面战略
管理
战略分析阶段
战略选择阶段
战略评价阶段
战略实施阶段
战略控制阶段
优化咨询
#
问题
客户反馈
单体应用
模块耦合程度
微服务划分与边界
单节点数据库
查询崩溃
IoT控制
命令超时失败, 响应慢
出错业务处理
发现问题
现有代码逻辑梳理
通过链路追踪，找性能瓶颈
SQL平台建设，发现数据库性能问题，优化SQL
服务器节点监控，应用监控，数据库监控
解决问题
代码
纯代码优化：N+1调用，事务问题
逻辑优化：订单失败，复杂业务流程优化
发布流程优化CI/CD
中间件优化：优雅停机，灰度方案节点打标，全链路日志
性能优化：业务并行处理，业务异步处理
数据库
不合理调用治理：批量更新，大事务，
慢SQL治理
数据库备份：主从优化，定时备份
配置调优
架构
高可用：服务发现，分布式
业务缓存优化，减少数据库调用：热点数据，对象缓存，多级缓存
分布式任务平台：分片执行
任务中心：批量平台
稳定性
告警平台
异常告警(空指针，接口调用成功率)
监控告警(服务器使用率)
业务告警(下单失败)
限流熔断
网关限流，业务限流，接口限流，外部调用限流
业务平滑处理
运营工具
业务数据多维分析
Oct 10, 2018
原则
#
高并发
高可用
高可靠
SLA(service level agreement)制定(吞吐量、响应时间、可用性、降级方案)
容量规划(流量、容量)
监控报警(机器负载、响应时间、可用率)
tracing
应急预案(容灾、降级、限流、隔离、切流量、可回滚)
成本
经济学原理
比较优势
服务器类型
分工协作
组合
货币解耦
MQ
规模效益
集群
高可用
#
负载均衡
#
流量切换 # 某服务器挂了
DNS切换
httpDNS # app配置，绕过运营商localDNS
lvs/haproxy # 切换故障的nginx
nginx # 切换故障应用
限流
#
思路
恶意请求流量只访问cache
穿透到应用的流量用nginx limit
恶意ip nginx deny
降级
#
开关集中化管理, 推送开关配置
开关前置 # nginx层做开关
可降级读服务 # 只读本地缓存、只读分布式缓存、只读默认数据
业务降级 # 部分业务异步，处理高优先级，分配流量保障系统可用
隔离
#
线程隔离
进程隔离
集群隔离
机房隔离
读写隔离
动静隔离
爬虫隔离
热点隔离
资源隔离
回滚
#
事务
代码库
部署版本
数据版本
静态资源版本
超时与重试
#
压测与预案
#
线下、线上
高并发
#
缓存
#
客户端
浏览器缓存 # Pragma, Expires, Cache-control
ajax
app缓存 # 大促时更新静态资源, 地图
客户端网络 # 代理服务器缓存
广域网
代理服务器(如CDN)
推送 或 拉取(回源)
镜像服务器
P2P
源站
接入层缓存 # 如页面缓存，用redis
url重写
一致性哈希
proxy_cache # 内存/SSD缓存内容
proxy_cache_lock # 一段时间的回源合并成一个
shared_dict # lua, 重启缓存不丢失
应用层缓存 # 如搜索，建议物品等
堆内缓存
堆外缓存 # local redis cache
分布式缓存(接入层后)
redis集群 # 异步化写入, lua-resty-lock(非阻塞锁)
对象缓存 # db和应用间的查询结果集
静态化, 伪静态化
服务器操作系统缓存
连接池线程池
#
异步化
#
队列
#
作用
服务解耦
异步处理
流量削峰/缓冲 # 如促销期
问题
丢失/失败 # 持久化，日志，报警, 数据校对修正(worker扫库)
重复 # 业务上防重
例子
redis扣库存->记录日志->同步worker->DB
消息总线可扩展 # x扩展不行，y扩展用专用总线(降低了灵活性), z扩展根据客户
减少拥挤 # 消息划分价值
扩容
#
无状态 # 应用无状态，配置有状态
尽可能浏览器端维护会话
分布式缓存放状态
拆分 # 加法组合，乘法功能
# 项目死于1到10，或10到100，因为解耦不够，无法重构
业务拆分
功能细分
读写 # 读缓存，写分库分表，聚合数据
AOP # 如CDN
模块 # 代码特征，如基础模块分库分表，数据库连接池
数据异构
例子
聚合数据表(一般KV存储) # 数据闭环(不依赖其它服务)
历史归档
并发化
选择工具
数据库 # rdb, nosql, hadoop
防火墙 # 墙需要的东西
日志 # 采集分析
用同品牌设备
慎用第三方
容错
隔离 # 不同步调用，限制异步调用(数量和超时)，能迅速发现故障
不单点 # 一切都出故障
不系统串联
功能支持启用禁用 # 实现wire on/wire off框架
服务方法
#
成本分析
#
# autonomy.design
表现
一个需求拉很多人，代码写进来就删不掉了
通用功能要么多种实现，要么参数过多
线上问题难定位，本地做不了有意义的测试，反馈周期特别长
本质
减少沟通
autonomy(自治): 减少沟通，功能可以删掉
问题: 产品从整体效果出发，开发从实现出发
依赖倒置
UI插槽, 服务集成
实现(服务)
编译时: 模板、函数替换
运行时: 组合对象、组合函数
实现(UI)
编译时: 页面模板替换, 显式组合与隐式组合
运行时: Vue插槽
feedback(反馈): 故障定位，测试反馈，发版反馈，用户反馈无响应
控制边界
进程
跨进程调用监控: 基础设施完善
OS强制配额、安全性: 基础设施好
内存隔离
函数
caller/callee索引: 同步调用栈、异步调用链、组件树
问题: 日志多，负责模糊
插件
控制变更
多进程
多进程部署
多租户
多变种
配置中心下发开关
consistency(一致性): 工具复用
用户可见的一致性: UI/UE设计，前端落地
autonomy: 上层业务推动
问题: 依赖修改要慎重
feedback: QA, KPI
拆分
组合关系
加法
乘法
一致性复用
扩展方式
#
服务化发展
进程内服务
单机远程服务
集群手动注册服务(nginx负载多实例)
自动注册和发现服务(zookeeper)
服务分组/隔离/路由
服务治理(限流/黑白名单)
AKF扩展立方
x轴 横向复制 # 复制服务或db, 瓶颈：内存缓存、特有数据
y轴 面向功能、服务、资源拆分 # 微服务
动词拆分 # 登录、搜索、推荐等
名词拆分 # 目录、库存、账户等
z轴 拆相近东西 # 数据分片(大小客户、地区、新旧等)
横向扩展 # 复制服务或数据分散负载，纵向扩展是升级设备
使用经济型系统
扩展数据中心 # 三实时站点备份: a(0.5b, 0.5c), b(0.5a, 0.5c), c(0.5a,0.5b), 尽量分散
使用云
微服务
#
单体应用问题
复杂: 模块多, 边界模糊, 依赖关系不清晰, 代码质量不统一
技术债务: 不坏不修
部署频率低: 迭代要部署整个应用，部署时间长，风险高。修复问题慢, 易出错
可靠性差: 某bug导致整个应用崩溃
扩展性差
阻碍技术更新
特征
服务组件化
按业务组织团队
负责的态度, 不再是交付给维护者
粗粒度通信, http(二进制协议)或消息总线
去中心化治理
去中心化管理数据
基础设施自动化
容错设计
演进式设计
原则
单一职责
自洽
轻量级通信
服务粒度: 边界(DDD中的界限上下文)
持续发布
工具链，自动化
契约
架构守护
灰度替换
*aaS
SaaS(software as a service)
PaaS(platform as a service)
aPaaS(application PaaS) # 简单配置产生任意需求的application
saPaaS(specific aPaaS) # 领域定制的aPaaS
GaPaaS(generator of aPaaS) # 脚手架，产生定制的aPaaS
云原生
#
介绍
cloud navtive, Pivotal 2013年提出
12-Factor
1 基准代码(code base)
一份代码，多份部署
2 依赖(dependences)
显式声明依赖
3 配置(config)
配置存储于环境变量中
环境变量粒度足够小，相对独立
4 后端服务(backing services)
后端服务作为附加资源, 与第三方服务不区别对待
5 分离构建、发布、运行(build, release, run)
构建: 代码转化到可执行包
发布: 可执行包结合配置
运行: 选定发布版本，按计划启动
6 进程(process)
多个无状态进程运行
7 端口(port binding)
网络服务通过端口绑定提供服务
完全自我加载不依赖网络服务器
8 并发(concurrency)
进程作为一等公民
通过进程模型扩展并发
9 易处理(disposability)
进程快速启动、优雅终止可最大化健壮性
追求最小启动时间, 收到SIGTERM优雅终止，突然死亡时保持健壮
10 环境等价(dev/prod parity)
开发环境等价线上环境
11 日志(logs)
日志作为事件流
应用本身使用stdout事件流，不考虑存储输出流，不管理日志
12 管理进程(admin processes)
管理进程不常驻, 一次性运行
使用同样环境、代码版本、配置、依赖隔离, 避免同步问题
提供REPL shell使一次性脚本变简单
Service Mesh
#
处于 TCP/IP 之上的抽象层
Serverless
#
只写业务代码，不关心服务器运行状态
BaaS
# Backend as a Service
FaaS
# Functions as a Service
Oct 10, 2018
平台服务
#
aPaaS
#
# platform as a service，介于IaaS和SaaS中间
将软件研发的平台做为服务，以SaaS的模式交付
组件化支撑和驱动
# 组件的发展决定paas广度，组件的聚合决定paas深度
# 对内固守组件边界，对外暴露标准接口
分层
平台组件
基础业务 # 不可见，影响全局，通用业务逻辑，对性能很敏感
业务
组件
设计
# 自描述的，这样就在设计和开发上解耦
确定边界
定义标准接口
确定核心功能
规范异常处理
开发
# 像开发dsl一样,来评判核心逻辑和接口，抽象度高
技术评审
定义接口
# 面向接口开发，也称为BDD
dubbo、grpc等
restful
接口设计
标准化
说明
服务路由
版本管理
授权管理
核心理念
# 体现在 服务、工具、模型、规范
开放 而非 封闭
合作 而非 限制
共享 而非 替代
重点关注
基础业务
组织架构和用户组
审批流
权限
通用模型
透明分布式缓存模型
分布式存储模型
分布式事务模型
效率工具
数据迁移工具
缓存配置工具
SaaS
#
aws线上云
微服务 + gRPC + k8s + Istio
Golang + TypeScript + Python
TiDB
行为分析
#
埋点
#
架构
数据采集
客户端采集
服务器采集
业务系统
第三方渠道
数据治理
ETL
实时ID mapping
元数据管理
数据质量管理: 数据校验, 实时导入监控，异常报警，debug数据查询，用户关联校验，数据质量看板
数据仓库
数据模型：Event, User, Item内容
实时导入系统
存储引擎、查询引擎
数据智能
特征工程
特征选择
模型训练: 深度学习, 自然语言处理，时序预测，GBDT/LR, AutoML
模型可视化
在线服务
工具
采集: SDK(JS, Android, iOS, 小程序，服务端，全埋点), ID Mapping, 归因链路
实施工具: 事件管理，变量管理，命名工具，埋点SLA配置, 预警配置，session管理，生命周期管理，tag管理，测试工具，ABTest工具
分析工具: 事件分析，漏斗分析，分布分析，留存分析，数据看板，热图分析，归因分析，自定义SQL查询, API管理，广告和活动效果监测
实现方式
代码埋点
全埋点、可视化全埋点（圈选）
规范
结构与命名清晰
方便历史版本对比
每个埋点数据质量负责到人（开发、测试、数据负责人）
数据统一管理
尽量用工具自动化
企业中台
#
数据
租户
用户
micro service
每个service监控
每个service不单点
单功能拆分，边界明确
service间只依赖sdk(好莱坞法则)，通过服务总线发现
servcie无状态接入
分类
内部服务 internal
# 内外服务用互相转化
文件上传
图像处理
数据挖掘
报表
外部服务 external
# 流控、质量监控、多链路备用、降级方案
邮件
短信
推送
cti
企业信息校验
业务服务 transaction
审批流
工作流
登录
海
核心服务 core
租户id服务
检索服务
报表服务
监控服务
k8s
服务总线
支持服务 supportive
文档
测试环境
沙盒同步
插件服务 plugin
集成服务 integration
事务服务
finance
CPQ
ERP
saas基础
计费
用户管理
联动
导入企业数据
调用aws或aliyun，提供webhook
服务的sdk
多语言sdk
降级
ha
apm
服务监控
# 用于发现问题、追查事故、评估缩容或扩容、评估降级
日志
接口
# 调用服务提供的监控接口
系统
# 容器提供
apm
# 客户端采样
可达性
# 由通用监控完成
工程
打包docker镜像
服务升级
灰度发布与AB test
提供api版本接口供客户端查询
服务总线
管理服务状态、位置
本地生活
#
服务与功能
...