架构:

1.定义

2.架构分类以及演进:

2.1 单机架构:

核心是部署在一台机器上,稳定性较差.

2.2 单体架构:

2.3 垂直应用架构:

按照职责对单体架构进行划分.

2.4 SOA架构:

类似于专家模式.

架构以服务为中心,服务之间按照特定的通信标准进行交互.

对程序进行了一层水平切分.

2.5 微服务架构:

在SOA架构中,明显的可以看到,兰师傅的沟通技巧是这个系统的核心,几乎所有的部门都需要通过这个进行交互,这样就会带来一系列的问题.比如每个服务都需要有复杂的设计.

而在微服务架构中,职责和服务拆分的会更加的细致,服务之间可以自由的建立连接方式,使程序的运行更加的高效.

2.6 总结:

3.企业级后端架构分析:

3.1 引入:

3.2 云计算:

在图中,如果使用云计算能力的话,只需要关注云计算服务的上层服务,而无需关心下层服务.

可以把精力更加专注的放在业务能力上面,而无需分心.

3.2.1 IaaS:

一个跨区域的组织,好比蛋糕店买房子,使用云计算的IaaS服务就好比找了一家房屋中介,屏蔽了物力资源的概念,用户不需要知道机房(服务器)在什么地方,所使用的电脑是什么型号等信息.

3.2.2 PaaS:

好比蛋糕店房子的装修,使用云计算的PaaS服务,就好比找了一家装修公司.对服务器进行维护和处理问题.

3.2.3 SaaS:

好比蛋糕师傅的培训机构,使用云计算的SaaS服务,类似于从蛋糕师傅培训机构寻找蛋糕师傅,他们专业技能强,上手快有保障,可以很快的进入店铺进行工作,类似于服务里面的成熟的组件.

3.2.4 FaaS:

好比使用蛋糕机,使用云计算的FaaS服务,就好比省略掉其他的所有部分,直接得到结果,类比使用成熟的服务(组件更大规模的集成).

3.3 云原生:

3.3.1:弹性资源:

不使用物理机而是使用虚拟机,扩展非常的容易,使用户不需要考虑底层.

资源存储类型:

3.3.2:微服务架构:

微服务架构:软件的组织方式.易于扩展.服务部署之间是松耦合的,但是可以有非常复杂的调用逻辑.

负载均衡层类似于大堂经理,对服务做一个分发.

不同的服务类型对应的不同的程序.

rpc服务存在着通信的压缩,在性能上要对http高一些,而且自带服务治理的能力.

而http服务大多使用json,内容上不存在压缩,可解释性相对较高.

RPC（Remote Procedure Call）叫作远程过程调用，它是利用网络从远程计算机上请求服务，可以理解为把程序的一部分放在其他远程计算机上执行。通过网络通信将调用请求发送至远程计算机后，利用远程计算机的系统资源执行这部分程序，最终返回远程计算机上的执行结果。

3.3.3:敏捷开发:

敏捷开发:在服务上线之后如何进行修改和运行维护.

本质上是一种适配于软件开发的工作流.

3.3.4:服务网格:

服务网格:服务与网络通信做一个解耦,对不同的语言所编写的代码做统一的治理.

如果不使用通信网格,则由不同容器之间的rpc/http框架之间进行通信.

而使用通信网格之后,则统一使用容器中的数据面进行通信,相当于多加了一层统一的代理.

3.3.5:蛋糕店:

4.企业级后端架构的挑战:

4.1 引入:

pod可以理解为是虚拟机.

4.2 离在线资源并池:

把整体的资源都分配给同一个进程,分为离线资源与在线资源,按照时间等因素进行调配.

随着在线资源进一步压缩,离线资源会逐步减少.

同一个机器怎么进行在线隔离?

4.3 自动扩缩容:

扩缩容指标:因为一般的微服务主要对cpu压力比较大,故一般以cpu的使用情况来判断.而对于某些特定的内存密集型,则使用内存.

而对io,kps的判断在业界有一定难度.

4.4 微服务亲合性部署:

不同的服务之间,耦合性非常的大,但确实是不同的人所维护的服务,通过某种方式降低成本.

就是把服务之间的网络通信,转换为物理机内部(共享内存等方式)的信息传输.

IPC是Inter-Process Communication的缩写，意为进程间通信或者跨进程通信，是指两个进程进行数据交换的过程。

4.5 流量治理:

4.6 CPU水位负载均衡:

一开始,a容器中的服务,均衡的调动两个b容器中的服务,在接收反馈的时候,发现第一个b容器所在的物理机由于cpu型号老旧等问题,导致占用内存较高,处理时间较长,通过负载均衡,那么就可以在调用这两个负载时,有选择性的调用高的负载,从而实现水位负载均衡.

5.架构实战:

5.1 引入:

提炼问题：

权重越高，意味着这个容器性能更好，可以分配更多的访问和任务。

5.2 静态自适应权重：

加一层代理。

对业务进程无感知。

5.3.1 Alpha版本：

通过回归存储的静态权重，解决紧急回滚问题。

5.3.2 Beta版本：

在这种情况下，动态权重决策中心似乎变成了一个单体架构，那么职责太多时候怎么办呢？

就像架构一样，再做一层微服务的拆分。

5.3.3 Release版本：

对动态权重决策中心做微服务拆分.

6.总结：

架构只是解决问题的一种方法.

代码重复撰写.

用户画像？

可拓展性.

7.秒杀系统:

7.1 系统设计方法论:

7.2 电商介绍:

社交电商:加强人与货的联系.

7.3 秒杀业务:

7.3.1 特点:

7.3.2 场景:

7.3.3 存储:

电商数据库表:

7.3.4 服务:

7.3.5 扩展:

CDN 提高静态资源访问请求的工具.

7.3.6 系统架构:

7.3.7 流程图:

7.3.8: 函数式编程:

把request变成model?

7.3.9 总结:

无状态:服务不存储状态(数据).

批量写入:降低压力.

最终一致性:过程中短暂不一致,最终一致.

8.黑灰产监控与防御:

8.1 常见的黑灰产:

8.2 常见的黑灰产业技术:

8.3 安全防护体系建设:

#架构3

原创