星猿科技的博客

本篇以前面讲过的“前浪微博”消息队列为例，给出架构设计中最重要的两个文档的模板和关键说明。

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

今天我们再聊开源项目，谈谈如何选择、使用以及二次开发。

架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题。这就需要我今天要和你分享的架构重构内功心法第三式：运筹帷幄。

本篇来聊聊架构重构内功心法的第二式：合纵连横。

说了那么多架构重构的难度，千万不要被困难所吓倒，架构师正是需要在原来一团乱麻中找到线索，然后重新穿针引线，帮助业务进一步腾飞发展。接下来我将分 3 期分享架构重构内功心法，今天先来看第一式：有的放矢。

本篇我们来聊聊互联网架构模板的“平台”技术

本篇将从“用户层”和“业务层”的角度谈谈常见的应用场景和关键技术。

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

上一期，我们介绍了互联网架构模板中的存储层技术。关于这部分内容，将逐层介绍每个技术点的产生背景、应用场景和关键技术，希望让读者可以对整体的技术架构有一个全貌认知。今天我们来聊聊互联网架构模板的“开发层”和“服务层”技术。

互联网的标准技术架构自底向上可以分为：存储层、开发层、服务层、网络层、用户层、业务层等六大层级，本篇我们先来聊聊互联网架构模板的“存储层”技术。

由于各行业的业务发展轨迹并不完全相同，无法给出一个统一的模板让所有的架构师拿来就套用，因此本篇以互联网的业务发展为案例，谈谈互联网技术演进的模式，其他行业可以参考分析方法对自己的行业进行分析。

对于技术人员来说，技术的快速发展当然是一件大好事，毕竟这意味着技术百宝箱中又多了更多的可选工具，同时也可以通过学习业界先进的技术来提升自己的技术实力。但对于架构师来说，除了这些好处，却也多了“甜蜜的烦恼”：面对层出不穷的新技术，我们应该采取什么样的策略？

微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，本片我们介绍常见的微内核架构及其实现。

微服务架构最佳实践的基础设施篇。

微服务架构最佳实践的方法篇介绍。

由于微服务的理念中也包含了“服务”的概念，而 SOA 中也有“服务”的概念，我们自然而然地会提出疑问：微服务与 SOA 有什么关系？有什么区别？为何有了 SOA 还要提微服务？这几个问题是理解微服务的关键，否则如果只是跟风拿来就用，既不会用，也用不好，用了不但没有效果，反而还可能有副作用。今天我们就来深入理解微服务，到底是银弹还是焦油坑。

为了帮助你在实践中更好的进行可扩展架构设计，将分别介绍几种可扩展架构模式，指出每种架构模式的关键点和优缺点。今天我们来探讨传统的可扩展模式，包括分层架构和 SOA，后面还会介绍微服务架构。

本篇开始我们讨论架构可扩展模式部分，这部分内容包括分层架构、SOA 架构、微服务和微内核等，先来聊聊架构的可扩展模式。

异地多活方案主要应对系统级的故障，例如，机器宕机、机房故障、网络故障等问题，这些系统级的故障虽然影响很大，但发生概率较小。在实际业务运行过程中，还有另外一种故障影响可能没有系统级那么大，但发生的概率较高，这就是今天我们聊的如何应对接口级的故障。

在掌握上篇提到的 4 大技巧的基础上，我们来探讨下跨城异地多活架构设计的 4 个步骤。

跨城异地多活是架构设计复杂度最高的一种，针对跨城异地多活架构设计的一些技巧和步骤，我们先来看 4 大技巧，掌握这些技巧算是完成好设计步骤的前提。

如果业务期望达到即使在灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构，本篇我们一起来看看异地多活架构。

本篇我们一起来看看常见的计算高可用架构：主备、主从和集群。

本篇我们一起来看看另外两种常见的高可用存储架构：数据集群和数据分区。

常见的高可用存储架构有主备、主从、主主、集群、分区，每一种又可以根据业务的需求进行一些特殊的定制化功能，由此衍生出更多的变种。本篇将针对业界通用的方案，来分析常见的双机高可用架构：主备、主从、主备 / 主从切换和主主。

如何保证我们能非常简单但是非常有效地做好复杂场景的全面分析，本篇我们讲讲排除架构可用性隐患的利器：FMEA 方法。

本篇我们讲讲CAP 的具体细节，简单对比一下 ACID、BASE 几个概念的关键区别点。

对于设计分布式系统的架构师来说，CAP 是必须掌握的理论，今天我们就来聊聊布鲁尔定理。

负载均衡算法数量较多，而且可以根据一些业务特性进行定制开发，今天我们就来聊聊负载均衡算法以及它们的优缺点。

单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。今天我们先来讲讲负载均衡的分类及架构。

本篇我们来看看介绍可以应对高并发场景的单服务器高性能架构模式：Reactor 和 Proactor。

本篇我们来看看单服务器高性能模式：PPC 与 TPC。

本篇我们来分析下缓存的架构设计要点。

本篇介绍各种高性能 NoSQL 方案的典型特征和应用场景。

读写分离分散了数据库读写操作的压力，但没有分散存储压力，当数据量达到千万甚至上亿条的时候，单台数据库服务器的存储能力会成为系统的瓶颈，为了满足业务数据存储的需求，就需要将存储分散到多台数据库服务器上。今天就来我们聊聊常见的分散存储的方法“分库分表”，其中包括“分库”和“分表”两大类。

高性能数据库集群的第一种方式是“读写分离”，其本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力；第二种方式是“分库分表”，既可以分散访问压力，又可以分散存储压力。本篇我们先来看看“读写分离”。

完成备选方案的设计和选择后，我们来聊聊架构设计流程第 4 步：详细方案设计。

本篇我们来聊聊架构设计流程第 2 步：设计备选方案，同样还会结合上期“前浪微博”的场景，谈谈消息队列设计备选方案的实战。

本篇我们来聊聊架构设计流程第 2 步：设计备选方案，同样还会结合上期“前浪微博”的场景，谈谈消息队列设计备选方案的实战。