[转]有意思的业务，架构设计，含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到底解决什么问题？》

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

 

[source]

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