分类目录归档：架构

2021
08-26

serverless看这一篇就够了 NEW

1. 无服务器（Serverless）计算是什么过去十年来，我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现，带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们看作某种形式的商品——厂商提供服务，我们掏钱购买。过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，做到当访问时，调入相关资源开始运行，... Read More >

2021
05-05

kafka redis发布订阅的区别和使用场景 NEW

背景Redis pub-sub就像是一个即弃即用系统，其中您产生的所有消息将立即传递给所有使用者，而数据却不保存在任何地方。关于Redis，您的内存有限。同样，生产者和消费者的数量也会影响Redis的性能。另一方面，Kafka是一种高吞吐量的分布式日志，可以用作队列。在这里，任何数量的用户都可以生产，而消费者可以在任何时候消费。它还为通过队列发送的消息提供持久性。对比使用Redis：如果您想要一种救火忘了的系统，那么您产生的所有消息都会立即传递给消费者。如果最关心速度。如果您... Read More >

2021
05-04

单点登录的三种实现方式 NEW

在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息... Read More >

2020
12-07

如何写出漂亮的代码-代码整洁之道

背景代码本就该是直接简单的，横就是横，纵就是纵，架构原本也本是清晰明了的，模块是模块，过程是过程。可随着项目生命周期的变长，随着需求不断的被实现，面对不同思想的人，不同场景的要求，不同技能水平的实施，就让原本平直的路走成了立交桥，织成了逻辑网。这时候再浏览代码，要走通某一个流程，即便是熟悉路况的“本地人”，编写代码的“原住民”也不一定能走的顺畅。Robert Martin的这句话非常合适：“唯一能有效测量代码质量的方式是每分钟说多少个What-the-Fk ”让我深入解释一下... Read More >

2019
06-06

高性能网络编程中的I/O模型

互联网服务端处理网络请求的原理首先看看一个典型互联网服务端处理网络请求的典型过程由上图可以看到，主要处理步骤包括：1. 获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）；2. 构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）；3. 返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）。设计服务端并发模型时，主要有如下两个关键点：1. 服务器如何管理连接，获取输入数据；2. 服务器如何处理请... Read More >

2019
06-05

单台服务器并发TCP连接数到底可以有多少

常识一：文件句柄限制在linux下编写网络服务器程序的朋友肯定都知道每一个tcp连接都要占一个文件描述符，一旦这个文件描述符使用完了，新的连接到来返回给我们的错误是“Socket/File:Can't open so many files”。这时你需要明白操作系统对可以打开的最大文件数的限制。进程限制执行 ulimit -n 输出 1024，说明对于一个进程而言最多只能打开1024个文件，所以你要采用此默认配置最多也就可以并发上千个TCP连接。临时修改：ulimit... Read More >

2019
05-27

高并发之服务熔断与降级

服务降级由于爆炸性的流量冲击，对一些服务进行有策略的放弃，以此缓解系统压力，保证目前主要业务的正常运行。它主要是针对非正常情况下的应急服务措施：当此时一些业务服务无法执行时，给出一个统一的返回结果。降级服务的特征原因：整体负荷超出整体负载承受能力。目的：保证重要或基本服务正常运行，非重要服务延迟使用或暂停使用大小：降低服务粒度，要考虑整体模块粒度的大小，将粒度控制在合适的范围内可控性：在服务粒度大小的基础上增加服务的可控性，后台服务开关的功能是一项必要配置（单机可配置文件，其... Read More >

2019
05-26

大型系统高可用的一般策略

负载均衡首先是应用服务器的负载均衡。负载均衡核心要解决的就是通过一个负载均衡服务器，将用户的请求分发给多个应用服务器，将多个应用服务器构建成一个集群，共同对外提供服务。这样的架构可以提高系统的处理能力，以解决高并发用户请求下的系统性能问题。事实上，负载均衡还可以实现系统的高可用。因为用户的请求是通过负载均衡服务器请求分发到不同的应用服务器上的。那么当某个应用服务器宕机的时候，负载均衡服务器可以通过响应超时或者其它的心跳策略，发现这个应用服务器不可用，就可以将请求转发给其它的服... Read More >

2019
05-20

互联网应用可用性的度量

概念业界通常用多少个 9 来说明互联网应用的可用性。示例比如说 QQ 的可用性是 4 个 9，就是说 QQ 的服务 99.99% 可用，这句话的意思是 QQ 的服务要保证在其所有的运行时间里只有 0.01% 不可用，也就是说一年大概有 53 分钟不可用。这个 99.99% 就叫做系统的可用性指标，这个值的计算公式是：年度可用性指标= 1 −（不可用时间/年度总时间）×100%。一般说来，两个 9 表示系统基本可用，年度停机时间小于 88 小时；3 个 9 是较高可用，年度停机... Read More >

2019
05-10

系统架构的演进之路-单体到SOA到微服务

单体系统的困难在微服务出现之前，互联网应用系统主要是单体系统，也就是说一个网站的整个系统由一个应用构成。如果是 Java，就打包成一个 war 包，一个 war 包包含整个应用系统，系统更新的时候，即使只是更新其中极小的一部分，也要重新打包整个 war 包，发布整个系统。这样的单体系统面临的挑战主要是什么呢？1.编译、部署困难2.随着网站的业务不断发展，系统会变得越来越庞大，最后变成一个巨无霸的系统。3.代码分支管理困难4.数据库连接耗尽5.新增业务困难6.发布困难微服务架构... Read More >

2019
04-11

如何使用sentry进行异常监控

系统架构中应用程序的监控非常重要。比如你是否遇到过这种问题：当用户向你抛出一个bug（或者说异常），而你却找不到异常出现的原因和时机，也很难去重现这种奇葩的事件，此时你有一种众里寻他千百度，那bug却不知在何处的感觉。所以，利用某种工具去实现系统的异常监控，方便我们及时查看结果，并且作出合理的处理，这对于每个架构师来说都是挺重要的。一、概念理解：1、异常与捕获异常指的是在程序运行过程中发生的异常事件，通常是由外部问题（如硬件错误、输入错误）所导致的。异常（Exception）... Read More >

2019
04-10

如何应对网站流量暴增

按照经验大概出问题地方是DB，磁盘io、CPU、带宽、连接数、内存其中的一个或几个。不同的业务，不同的系统设计，出问题的地方会有所不同。如果流量增大数倍，势必某个资源会在瞬间被榨干，然后所有的服务都会“开小差”，引起用户的抱怨。而解决问题的关键，是在问题发生时，尽量减少出问题的资源被访问。1、流量暴涨的原因　   一般情况下，引起网站流量暴增大致为以下两种情况　　1、不可预测流量（网站被恶意刷量；CDN回源抓取数据；合作业务平台调取平台数据等）　　2、可预... Read More >

2019
04-07

微博朋友圈亿级Feed流如何设计

简介Feed流是Feed + 流，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。 在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等，所以Feed流就是不停更新的信息单元。当前最流行的Feed流产品有微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，还有一些变种，比如私信、通知等，这些系统都是Feed流系统，接下... Read More >

2019
04-06

秒杀如何设计

秒杀难点：1、突发流量、数据热点2、数据一致性、短暂混沌态如果采用传统的数据库进行数据存储，对同一资源的争抢，就会面临严重的锁冲突问题。一般是通过一个前置的，速度更快的存储顶在前面，这就涉及到源库和目标库的数据同步问题。从商品资源的上架，到秒杀的完成，会经历一个短暂的混沌状态，出现数据不一致的情况。在请求量非常集中的情况下，还会产生并发问题，个体的行为和结果，是不可预测的。系统层面，秒杀业务如何设计？客户端，app或者浏览器站点层，访问后端数据服务层，屏蔽底层数据细节，提供数... Read More >

2019
04-03

如何实现分布式事务及BASE和CAP理论

事务定义简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。数据库本地事务数据库事务中的四大特性 ACIDA：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。C：一致性(Consistency)... Read More >

2019
04-01

基于rebase的Git工作流

使用Git在多人协作的过程中，我们也会面临如何运用好Git的问题。这种情况下，就出现了各种各样的Git Workflow，而本文将介绍一种基于rebase的工作流，这种工作流也是目前开源社区所比较推崇的做法，了解了这种工作流之后可以更规范的使用Git一、Rebase和Squash1、Rebase是什么，为什么使用Rebaserebase是能够将我们对代码的更改从一个分支集成到另一个分支中的git命令之一（另一个命令是Merge）。使用rebase的一个风险在于，它会改写com... Read More >

2015
11-03

加密算法的对比和总结

一、单向散列算法也称为Hash（哈希）算法。是一种将任意长度的消息压缩到某一固定长度（消息摘要）的函数（该过程不可逆）。Hash函数可用于数字签名、消息的完整性检测、消息起源的认证检测等。常见的散列算法有MD5、SHA、HMAC、RIPE-MD、HAVAL、N-Hash、Tiger等。1. MD5算法MD5消息摘要算法（Message Digest Algorithm 5）。对MD5算法简要的叙述可以为：MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子... Read More >