索引：
架构好文学习，攒~~
名词解释：
Apache MINA： 百度百科
HAProxy： 百度百科
1.0 架构笔记：
优点：模型结构简单---理解起来简单；开发起来简单；部署起来也简单。
缺点：效率和扩展---这个模型实际上是一个高功耗低效能的模型，不活跃的连接在那做高频率的无意义轮询，高频有多高呢，基本在 100 ms 以内，
你不能让轮询太慢，比如超过 2 秒轮一次，人就会在聊天过程中感受到明显的会话延迟。 随着在线人数增加，轮询的耗时也线性增长，
因此这个模型导致了扩展能力和承载能力都不好，一定会随着在线人数的增长碰到性能瓶颈。
2.0 架构笔记：
改进点：业务功能体验的提升上---针对无法及时提供服务的顾客，可以排队或者留言。 针对纯文字沟通，提供了文件和图片等更丰富的表达方式。
另外支持了客服转接和快捷回复等方式来提升客服的接待效率。
3.0 架构笔记：
改进点：业务划分服务，且服务进行分层---服务化的第一个问题如何把一个大的应用系统切分成子服务系统。
按业务重要性级别划分了 0、1、2 三个级别不同的子业务服务系统。 另外就是独立了一组接入服务，针对不同渠道和通信方式的接入端。
服务架构&分层---a.UI接入层 --- 客服用(web/app..)系统，员工用(web/app/pc...)
b.负载均衡层 --- TCP长连接，HTTP短连接
c.路由服务层 --- 路由 Tracker
d.业务服务层 --- 业务子系统及API服务
e.基础服务层 --- 基础框架服务(安全/风控/资源分配...)
f.资源服务层 --- DB/Cache/NoSQL/MQ....
消息投递模型---不再是轮询了，而是让终端每次建立连接后注册接入点位置，消息投递前定位连接所在接入点位置再推送过去。
这样投递效率就是恒定的了，而且很容易扩展，在线人数越多则连接数越多，只需要扩展接入点即可。
使用了 MongoDB 来单独存储量最大的聊天记录。
4.0 架构笔记：
拍拍网消息缺陷：a.复制工程，定制业务开发，多套源码维护成本高
b.独立部署，至少双机房主备外加一个灰度集群，资源浪费大
系统持续演进：面向平台---始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，
剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。
部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。
细粒度服务开发---更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。
架构VS业务： 技术架构没有绝对的好与不好， 技术架构总是要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、
环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期，才可能发挥最好的效果。
蒙
2017-08-02 09:20 周三