索引：

架构好文学习，攒~~

名词解释：

　　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 周三