转载

从零开始学架构

2019-3-29 张子阳 推荐: 4 难度: 2

从零开始学架构

忘了从哪儿看到过这本书,因为自己也在做架构方面的工作,架构方面的书自然是多多益善,于是就买来读了。这本书的难度适中,基本上是从一个比较高的角度,把互联网系统采用的架构总结和梳理了一遍。这本书并没有深入到每一个技术的细节,因为很多细节都需要专门的一本书去讲解,而是讲解了每项技术用来解决的问题,以及应用该技术所可能产生的附加影响。

全书分为了20个章节,每个章节涉及一个技术点。全书330页,所以每章只有15页左右,比较短小精悍。在实际工作中,可以作为解决方案的参考,然后再根据选择的方案,进一步研究和实施。

下面是全书的一些要点:

架构设计的主要目的是解决软件系统复杂度带来的问题(这里不见得苟同。比如原本的系统很简单,为了提升性能,更改后的架构可能反而引入了复杂性)。

架构设计的原则

  • 合适优于业界领先
  • 简单优于复杂
  • 演化优于一步到位

存储高性能

读写分离

主要问题:同步复制有延迟,注册完立即登录可能登录失败,因为登录时读操作,而此时还没有同步过去。

解决方案:

  1. 紧随“写操作”后的“读操作”也读主库。
  2. 二次读取,当从库读无数据时,从主库读。
  3. 关键业务使用主库,非关键业务采用读写分离。(后台管理使用主库,前台用户读写分离)

分库

主要问题:join操作、事务

分表

水平分表、垂直分表

这章还概括讲述了 NoSQL、列式存储数据库、文档型数据库 等几种数据存储。

计算高性能

计算高性能分为单机高性能和集群高性能。

对单机高性能,主要讲了服务器处理连接和请求的几种模式:PPC(Process per Connection)、prefork(提前创建子进程模式)、TPC(Thread per Connection)、prethread(提前创建子线程)

Reactor模式,就是创建一个进程池,进程处理完连接后并不销毁,而是继续服务新进来的连接。

对集群高性能,则主要采用负载均衡。

负载均衡分了几层:DNS负载均衡、硬件负载均衡(F5、A10)、软件负载均衡(Nginx、LVS)。

分布式系统的一些理论

CAP

CAP是分布式计算的一个基础理论,CAP分别代表Consistency、Availability、Partition Tolerance。这里理论的内容是:在一个分布式系统( 指互相连接并共享数据的节点的集合)中,当涉及读写 操作时,只能保证一致性( Consistence )、可用性( Availability )、分区容错性( Partition Tolerance) 三者中的两个,另外一个必须被牺牲。

  • 一致性:对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。
  • 可用性:非故障的节点在合理的时间内返回合理的响应(没有发生错误或者超时)。
  • 分区容错性:当出现网络分区后,系统能够继续工作(function)。

实际中,因为网络不可能100%可靠,所以P是一个常态,那么实际上就是CP和AP两种情况。显然,这是两个矛盾的状态:

假设集群中的两个节点N1、N2,当N1和N2之间的网络中断后,假设客户端C1向N1中写入了数据,客户端C2从N2中读取,那么必然是:如果要保证一致性,那么N2就只能返回错误信息:未能实现与N1的同步,此时就牺牲了可用性。如果要保证可用性,那么N2返回的就可能并非最新的数据。

ACID

CAP有时会和ACID进行比较,ACID是为了保证数据库事务正确性而提出来的理论。

  • Atomicity(原子性):一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事 务在执行过程中发生错误,会被回滚到事务开始前的状态, 就像这个事务从来没有执行过一样。
  • Consistency(一致性):在事务开始之前和事务结束以后,数据库的完整性没有被破坏。
  • Isolation C 隔离性):数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交( Read uncommitted )、读提交( read committed ) 、可重复读( repeatable read )和串行化( Serializable ) 。
  • Durability (持久性):事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

BASE

BASE 是指基本可用( Basically Available )、软状态( Soft State )、最终一致性( Eventual Consistency )。是对CAP(强一致性)的补充。

  • 基本可用:分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
  • 软状态:允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP 理论中的数据不一致。
  • 最终一致性:系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

存储高可用

  • 主备模式:备机仅做备份,客户端不进行读写,故障时切换到备机。
  • 主从模式:备机可做读操作。

分布式事务算法

  • 两段式提交
  • 三段式提交

业务高可用

  • 降级:降级指系统将某些业务或接口的功能降低,可以是只提供部分功能,也可以是完全停掉所 有功能。例如,论坛可以降级为只能看帖子,不能发帖.
  • 熔断:降级的目的是应对系统自身的故障,而熔断的目的是应对 依赖的外部系统故障的情况。例如A依赖于B,当B请求非常慢时,可以直接返回B错误。
  • 限流:指只允许系统能够承受的访问量进来,超出系统访问能力的请求将被 丢弃。

微服务实践

  • 服务粒度:既不能太细也不能太粗,一般取决于服务复杂性和团队规模。
  • 服务拆分:可基于业务逻辑、可扩展性、可靠性、性能等指标进行拆分。
  • 基础设施:服务发现、服务路由、服务容错、服务监控、服务跟踪、服务安全、自动化测试、自动化部署、配置中心、API网管。

本书后面部分讲述了SOA、微服务、微内核以及互联网架构的一些演进,这部分有点像前面章节基础知识的一些应用。

感谢阅读,希望这篇文章能给你带来帮助!

原文  http://www.tracefact.net/reading/059.html
正文到此结束
Loading...