架构设计内容分享(二百一十)：设计一个大并发、大数据的系统架构，说说设计思路

目录

大并发/大数据的软件有如下特点

大并发/大数据的架构目标有如下几个

大并发/大数据的设计思路与原则

大并发/大数据的分层架构

1 接入层的架构方案：

第二三层：应用层/服务层架构方案

第四层：数据层架构方案

第五层：基础设施层架构

高并发核武器：单元化+异地多活设计

---

大并发/大数据的软件有如下特点

• 用户多，分布广泛

• 大流量，高并发

• 从小到大，渐进发展

• 以用户为中心

• 海量数据，服务高可用

• 安全环境恶劣，易受网络攻击

• 功能多，变更快，频繁发布

大并发/大数据的架构目标有如下几个

• 高性能：提供快速的访问体验。

• 高可用：网站服务一直可以正常访问。

• 可伸缩：通过硬件增加/减少，提高/降低处理能力。

• 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。

• 安全性：提供网站安全访问和数据加密、安全存储等策略。

• 敏捷性：随需应变，快速响应。

大并发/大数据的设计思路与原则

1.演进原则

优秀的架构和产品都是一步一步迭代出来的，用户量的不断增大，业务的扩展进行不断地迭代升级，最终演化成优秀的架构。

• 早期项目，由于团队规模有限，技术经验不足，往往使用一个简单的单体架构、单节点DB。

• 随着流量增加和业务演变，需要不断修正系统架构中的问题点，基于后面的几个原则，一点一点的进行系统演进

演进原则：高并发/大数据系统的演进是循序渐进的，以在高并发、大数据场景下不断优化用户体验为目标。

2.单一职责（ Single Responsibility Principle）原则

定义：对一个类而言，应该仅有一个引起它变化的原因。

说明：一个类应该是相关性很高的封装，类只实现一个功能。

很多的时候，我们代码中有大量的上帝类，所谓上帝类，

把不应该是一个类的功能也往自己身上揽，大包大揽，导致内聚性就会很差，

内聚性差将导致代码很难被复用，不能复用，只能复制（Repeat Yourself），其结果就是一团乱麻。

3.开闭原则（Open Closed Principle）

定义：软件中的对象应该对于扩展是开放的，对于修改是关闭的。面对新需求，对程序的改动应该是通过增加代码实现的，而不是修改现有代码来实现。

说明：当软件需要变化时，我们尽可能的通过扩展的方式来实现变化，

比如通过继承，通过装饰者模式来增加新的功能，而不是通过修改已有的接口来实现，一旦修改接口，上层调用的地方均需要修改。

开闭原则是面向对象设计的核心所在，遵循开闭原则的最好手段就是抽象。

防止变异(Protected Variations)

问题：如何设计对象，子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？

解决方案：分离变与不变，  识别变化或不稳定的地方，抽象出稳定的接口。

开发人员应该仅对程序中频繁出现变化的那些部分做出抽象，如果对于应用程序中每个部分都做刻意的抽象并不是个好主意。

拒绝不成熟的抽象和抽象本身一样重要。

4.高内聚低耦合/迪米特原则（Law of Demeter）

定义：

• 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的互相引用。

• 如果中间一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。

一个对象应该对其他对象有最少的了解。也被称为最少知识原则。

该原则首先强调的是在类的结构设计上，应该尽可能低的设计成员的访问权限。

其根本思想是强调了类的松耦合，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会波及有关系的类。

也就是说，一个类应该对自己需要耦合或调用的类知道的最少，类与类之间的关系越密切，耦合度越大，那么类的变化对其耦合的类的影响也会越大，这也是我们面向对象设计的核心原则：低耦合，高内聚。

什么是直接的朋友？

每个对象都必然与其他对象有耦合关系，两个对象的耦合就成为朋友关系，这种关系的类型很多，例如组合、聚合、依赖、关联等。

其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类