有意思的业务，有意思的架构设计（含Google三驾马车）

架构师之路年终总结（十一）-业务架构篇

脱离业务的架构设计都是耍流氓，这些典型业务的流程与架构，应该怎么设计呢？

如果之前错过，欢迎回顾。

1.《多点登录，消息漫游，架构设计》

手机端和PC端，如何同时登录，同时收消息？

换一个手机，能不能拉取到历史消息？

2.《离线消息，怎么保证不丢失？》
批量拉取，按需拉取，分页拉取，应用层ack等很多架构设计思路在里面，有点意思。

3.《消息顺序性，到底怎么保证？》

1对1消息，怎么保证发送方发送时序，与接收方展现时序一致？

群消息，怎么保证所有群友展现时序一致？

充值支付消息，怎么保证一个用户发起请求顺序，与服务器执行请求顺序一致？

4.《群聊架构，为什么这么复杂？》

群发一条消息，可能要扩散500个请求？

5.《GFS架构启示 | Google File System》

如何通过单点简化设计？

如何保证单点高可用？

存在单点的系统如何性能优化？

如何保证文件系统的可靠性与完整性？

如何保证多个副本的一致性？

画外音：Google爸爸，就是经典。

6.《Google MapReduce到底解决什么问题？》

定义问题域，往往比解决问题更难。

7.《Google MapReduce有啥巧妙优化？》

分区函数，合并函数，文件切分的思路究竟是什么？

8.《Google MapReduce架构设计》

如何降低系统设计复杂度？

为啥master不用保证高可用？

如何保证worker高可用？

幂等性设计的妙用？

长尾问题如何优化？

9.《为什么说，MapReduce，颠覆了互联网分层架构的本质？》

透过现象看本质，才能看到MR架构的巧妙之处。

附一篇：《互联网分层架构的本质》

画外音：MR架构打破的就是它。

10.《Google BigTable到底解决什么问题？》

定义问题域，往往比解决问题更难。

画外音：我去，我以为这个系列已经写完了，BigTable似乎还没写完，大家觉得要不要继续？

思路比结论重要。

附一篇：

《PHP怎么搞长连接》

画外音：谁是世界上最好的语言？

架构师之路-分享通俗易懂的技术文章

推荐阅读：

《“技术人如何带团队”-年终总结（六）》

《“MySQL必知必会”-年终总结（七）》

《“算法与数据结构”-年终总结（八）》

《“1分钟学架构与运维”-年终总结（九）》

《“面架构师，面试问什么”-年终总结（十）》