洋蔥

贪婪,找不到比这更好的词了,是件好事。

在前面的专栏里,有同学留言说想看看具体的架构设计文档。由于信息安全的原因,再加上稍微复杂的系统,设计文档都是几十页,因此专栏无法直接给出详细的文档案例。但我认为提供一个架构设计文档模板还是很有必要的,可以方便你在实际进行架构设计的时候更好地编写相关文档。我还以前面讲过的“前浪微博”消息队列为例,给出架构设计中最重要的两个文档的模板和关键说明。这个案例文档仅给出一些关键内容供你参考,部分细节无法全面覆盖或者完全保证正确。

阅读全文 »

专栏截止到上一期,架构设计相关的理念、技术、实践已经基本讲完,相信你一路学习过来会有一种感觉,这些内容主要都是讲后端系统的架构设计,例如存储高可用、微服务、异地多活等,都是后端系统才会涉及。事实上确实也是如此,通常情况下我们讲架构设计,主要聚焦在后端系统,但这并不意味着App、前端就没有架构设计了,专栏所讲述的整套架构设计理念,虽然是来源于我的后端设计经验,但一旦形成完善的技术理论后,同样适应于App和前端。

首先,先来复习一下我的专栏所讲述的架构设计理念,可以提炼为下面几个关键点:

  • 架构是系统的顶层结构。
  • 架构设计的主要目的是为了解决软件系统复杂度带来的问题。
  • 架构设计需要遵循三个主要原则:合适原则、简单原则、演化原则。
  • 架构设计首先要掌握业界已经成熟的各种架构模式,然后再进行优化、调整、创新。

复习完我们就可以进入今天的正题,我来谈谈App架构的演进,以及上面这些架构设计关键点是如何体现的。

阅读全文 »

在前面的架构重构内功心法“有的放矢”和“合纵连横”中,我提到架构师需要从一大堆问题中识别关键的复杂度问题,然后有的放矢地通过架构重构来解决。但是通常情况下,需要架构重构的系统,基本上都是因为各种历史原因和历史问题没有及时处理,遗留下来逐渐积累,然后到了一个临界点,各种问题开始互相作用,集中爆发!到了真正要开始重构的时候,架构师识别出系统关键的复杂度问题后,如果只针对这个复杂度问题进行架构重构,可能会发现还是无法落地,因为很多条件不具备或者有的问题没解决的情况下就是不能做架构重构。因此,架构师在识别系统关键的复杂度问题后,还需要识别为了解决这个问题,需要做哪些准备事项,或者还要先解决哪些问题。这就需要我今天要和你分享的架构重构内功心法第三式:运筹帷幄。

阅读全文 »

上一期我给你讲了我的架构重构内功心法的第一式:有的放矢,需要架构师透过问题表象看到问题本质,找出真正需要通过架构重构解决的核心问题,而不是想着通过一次重构解决所有问题。

今天我来传授架构重构内功心法的第二式:合纵连横。

阅读全文 »

当业务规模比较小、系统复杂度不高时,运维、测试、数据分析、管理等支撑功能主要由各系统或者团队独立完成。随着业务规模越来越大,系统复杂度越来越高,子系统数量越来越多,如果继续采取各自为政的方式来实现这些支撑功能,会发现重复工作非常多。因此我们自然而然就会想到将这些支撑功能做成平台,避免重复造轮子,减少不规范带来的沟通和协作成本。

今天,我就来聊聊互联网架构模板的“平台”技术。由于每个平台本身都是一个庞大的体系,专栏只是介绍一下平台的核心职责和关键设计点,具体细节就不详细展开了。

阅读全文 »

除了复杂度,互联网业务发展的另外两个关键特点是“高性能”和“高可用”。通常情况下,我们在设计高可用和高性能系统的时候,主要关注点在系统本身的复杂度,然后通过各种手段来实现高可用和高性能的要求,例如我前面介绍的计算高性能架构模式、存储高可用架构模式等。但是当我们站在一个公司的的角度来思考架构的时候,单个系统的高可用和高性能并不等于整体业务的高可用和高性能,互联网业务的高性能和高可用需要从更高的角度去设计,这个高点就是“网络”,所以我将相关措施统一划归为“网络层”。注意这里的网络层和通常理解的如何搭建一个局域网这种概念不一样,这里强调的是站在网络层的角度整体设计架构,而不是某个具体网络的搭建。

接下来我将介绍互联网架构模板的“网络层”技术的几个关键架构设计点,部分内容专栏前面已经有深入阐述,今天作为概要的总结把它们归纳一下。

阅读全文 »
0%