【问题标题】:Multi-platform social networking application development architecture [closed]多平台社交网络应用程序开发架构
【发布时间】:2014-01-21 16:29:18
【问题描述】:

我正在考虑一些社交媒体应用程序,例如 facebook 或linkedin。我在http://highscalability.com/之类的网站上看了很多文章,都没有找到正确的答案。

因为,目前最大的应用程序都使用他们的自定义系统。他们使用自定义文件系统或自定义数据库引擎或自定义 Web 服务器。他们不使用原始的 iis、apache、mssql、mysql、windows 或 linux。他们使用大量的编程语言来解决不同的问题。由于他们的负担,这对他们来说没问题。他们必须计算每一点或一些东西。他们从一些小环境开始,遇到了问题并看到了瓶颈。因此他们建立了新的解决方案。

现在,我们可以找到一些关于他们当前系统的文章。但是对于什么是最好的开始,我们没有答案。

我需要学习“什么样的架构才是正确的开始?”的答案

我对此有一些想法,但我们需要确定这一点。

我们认为,

将mysql用于关系数据库。以及像 memcached over mysql 这样的缓存机制。还有一个业务层的rest api。我们认为使用 python 来编码 rest api。并且所有系统都在合适的 linux 发行版上运行。在所有这些环境都可以之后,我们可以使用任何语言或系统的 UI。它可以是 Web 的 PHP 站点,也可以是 IOS 或 Android 的原生应用程序。

我们需要您的建议。非常感谢。

(我是一个很好的读者,但这是我的第一个问题。我希望没有问题。)

【问题讨论】:

  • 从你的盲点来看,这可能是“正确的”。从我的盲点来看,基于 Windows 的堆栈可能是“正确的”。这不是一个可行的问题。您正在寻找解决方案,但没有具体说明问题。
  • 我不同意“搁置”的观点。正如您在答案中所看到的那样,这不是一个拍摄问题,而是选择适当的选择。 span>

标签: performance architecture scalability social-networking development-environment


【解决方案1】:

根据去年的一个类似问题,我compiled 一些较大的社交网站使用的技术和技术。

以下架构概念在此类网站中普遍存在:

可扩展性

  • 缓存(大量,跨多个层和层)
  • 数据分片(最好按数据局部性标准)
  • 用于经常引用数据的内存 DB
  • 高效的线路级协议(与企业通常认为的最先进的协议相反)
  • 异步处理

灵活性

  • 将面向服务的架构作为基线原则
  • 解耦和分层组件
  • 异步处理

可靠性

  • 异步处理
  • 复制
  • 单元架构(独立操作的子集,例如按地理标准)

注意:如果您创建一个新站点,您不太可能拥有这些超大型站点所面临的那种扩展性或可靠性要求。因此,最好的建议是从小处着手,但要保持灵活性。一种方法是使用一开始很简单但以后可以灵活扩展的应用程序框架,例如姜戈。

【讨论】:

  • 真的谢谢你。特别是您分享的幻灯片对我很有帮助。我最大的问题是业务层。它应该是私有 API 吗?它可以是一个休息 API 或其他。但它应该是一个通过 HTTP 工作的 API 吗?这个很贵吗 ?我认为“Apache Thrift”会告诉我我需要什么。再次感谢。
  • 很高兴有帮助。我建议从小处着手——将业务层编写为本地可调用(最初是同一个框),然后在其上添加一个 REST API。对于 API,区分技术(例如 REST、WS*/SOAP,假设 HTTP 作为传输似乎公平)和定义实际对象和操作的业务语义。对于这项技术,请尽可能使用现有的框架和插件,除非您绝对必须这样做,否则不要重新发明轮子,因为还没有人解决您的特定问题。对于业务语义,为了简单起见,我将从您自己的“私有”API 开始。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-11-23
  • 2015-10-09
  • 2015-10-24
  • 1970-01-01
  • 1970-01-01
  • 2010-11-28
相关资源
最近更新 更多