版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/z50L2O08e2u4afToR9A/article/details/88324884
架构师之路年终总结（十一）-业务架构篇
脱离业务的架构设计都是耍流氓，这些典型业务的流程与架构，应该怎么设计呢？
如果之前错过，欢迎回顾。
1.《多点登录，消息漫游，架构设计》
手机端和PC端，如何同时登录，同时收消息？
换一个手机，能不能拉取到历史消息？
2.《离线消息，怎么保证不丢失？》
批量拉取，按需拉取，分页拉取，应用层ack等很多架构设计思路在里面，有点意思。
3.《消息顺序性，到底怎么保证？》
1对1消息，怎么保证发送方发送时序，与接收方展现时序一致？
群消息，怎么保证所有群友展现时序一致？
充值支付消息，怎么保证一个用户发起请求顺序，与服务器执行请求顺序一致？
4.《群聊架构，为什么这么复杂？》
群发一条消息，可能要扩散500个请求？
5.《GFS架构启示 | Google File System》
如何通过单点简化设计？
如何保证单点高可用？
存在单点的系统如何性能优化？
如何保证文件系统的可靠性与完整性？
如何保证多个副本的一致性？
画外音：Google爸爸，就是经典。
定义问题域，往往比解决问题更难。
分区函数，合并函数，文件切分的思路究竟是什么？
如何降低系统设计复杂度？
为啥master不用保证高可用？
如何保证worker高可用？
幂等性设计的妙用？
长尾问题如何优化？
9.《为什么说，MapReduce，颠覆了互联网分层架构的本质？》
透过现象看本质，才能看到MR架构的巧妙之处。
附一篇：《互联网分层架构的本质》
画外音：MR架构打破的就是它。
定义问题域，往往比解决问题更难。
画外音：我去，我以为这个系列已经写完了，BigTable似乎还没写完，大家觉得要不要继续？
思路比结论重要。
附一篇：
画外音：谁是世界上最好的语言？
架构师之路-分享通俗易懂的技术文章
推荐阅读：