QT语音是如何设计的

QT语音是如何设计的

本来让我写软件构造，我是写不出来什么东西的，代码写的不咋地，主要是不会API。
夏季学期选了这么一门腾讯分布式系统，结果腾讯的老师一棍子先甩过来，一下子就懵了。
他问，软件设计核心是什么。
我寻思这我好歹跟着软构王老师学了这么久，还答不出来吗。
答了一堆什么诸如“兼顾正确性和鲁棒性，实现功能什么的”
结果腾讯分布式的徐老师说“你说的都是对的，但是不在点子上”
那么问题来了：软件设计核心是什么？
软件设计核心：分离+抽象
分离：体现在功能(面向过程)和职责(面向对象)划分，实现高内聚低耦合，其目的是保障系统具有独立演化能力。
• 抽象：体现在提炼(算法)和抽取(共性)，实现高复用低内涵，其目的是保障系统具有变化包容能力。

工程上的分离

对计算机来说，交通就是比特流流转，我们要做到的就是从工程上将耦合起来的数据分离开。

以QT语音为例

早期的QT语音虽然同时具备打赏和群发消息喇叭以及连麦的功能。但是会出现群发喇叭和打赏同时占用连麦导致炸麦。
QT语音认为信令（群发喇叭和打赏业务）并不要求即时通讯，所以将信令业务和语音业务分离。因为信令比如群发喇叭或者送花，排名变化，以至于现在的弹幕都是可延迟的，而上台开麦的语音却不能忍受延迟。不能等待与信令包一同发送，那就干脆分离。（比如斗鱼，斗鱼的弹幕是非实时的，很多情况下你发出的弹幕压根不会在某些人的屏幕上，可能弹幕是随机推送的）

分离后，变换通信协议，不影响业务逻辑，同时业务逻辑可以兼容多种协议。

分离后，信令和语音可独立采取不同策略独立演进。以后对信令的修改和升级将不会影响到语音。还是以斗鱼为例，斗鱼客户端的礼物抽奖功能经常升级，但是你的手机不升级，在数个版本以内仍能观看斗鱼直播，只是参与不了某些抽奖活动。

更进一步的分离解耦

业务逻辑和广播分离。
分离后，业务app可以聚焦业务逻辑实现，业务接口完成广播任务派发，信令接口负责实际的广播执行。（将客户端与实际逻辑分隔开）

将在线系统和业务系统分离，分离后，业务系统可以快速发布，迭代和大流量冲击，而不影响用户在线业务的可靠性。
使用kafka队列，可以更进一步做到服务之间解耦合
Kafka：一种分布式，基于发布/订阅的消息系统。高吞吐率，基于磁盘大文件顺序读写，提供O(1)的消息持久化能力，能够支持TB级别的数据。
至此，QT语音的分离完成

工程学上抽象

忽略次要，保留主要部分。软件的逻辑功能就是工程的高度抽象。
作软件的时候该舍弃要舍弃，摒弃细节抽取共性。

以QT业务为例

我们在服务器之间作强耦合，业务处理比较麻烦，这时便用代理服务器，将信息推送到代理服务器上，关心这些信息的用户需要代理服务器订阅信息，这样便松耦合了，并不需要服务之间判断通知顺序。（proxy模式）

最后，老师总结了所有的软件构造典型设计模式和它们的特征。

软件设计模式
• 创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
• 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
• 行为型模式：命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式。
软件设计核心：分离和抽象
• 创建型模式：分离对象创建时空，抽象创建过程。
• 结构型模式：分离对象服务接口，抽象整体与局部，异构类型。
• 行为型模式：分离对象交互耦合关系，抽象交互内容。
设计模式是演绎在特定场景下分离和抽象机制的运用
在之后的课还没上。建议上完了再补。