分类目录归档:架构演变

架构师图谱·微服务&消息队列篇

1. 概述

“架构师图谱”是一个很宏大的命题,特别是优秀的架构师自身也是“由点到面再到图”,一点点成长积累起来,尝试写这系列文章的目的更多的是结合自身的一些经验和理解,来解读工程师和架构师所应具备的技能模型,这里会更偏向于后端技能,依赖于开源技术、云原生或者其他第三方服务。重点介绍一些技术栈、设计理念和适应场景,这些可以作为我们选型时的依据。所谓“架构即决策”,是在一个有约束的盒子中寻求最优解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等编织、掺杂在一起的综合体。本质上无优劣,但是存在恰当的架构用在合适的软件系统中,而这些就是决策的结果。

1.1 序章

一个技术图谱:

计划会分三个篇章来介绍:

  1. 微服务&消息队列篇:重点聚焦在微服务和常用的消息队列,包括相关的选型以及一些理论基础
  2. 数据库&分布式篇:主要集中在数据库、分布式(一致性/锁/缓存/发号/任务调度等)
  3. 尾篇:分享一些流媒体、Devops、项目管理、团队建设方向的一些经验

完整的思维导图:

2. 微服务

谈到微服务,通常会和SOA、微内核等架构进行比较,不过SOA粗粒度服务、庞大的ESB,在互联网更注重敏捷交付的场景,落地较少。微内核架构和微服务架构没有本质上的区别,但是更多的面向插件化场景,在一些类似营销、风控、工作流、管线等场景,对应的微服务可以采用微内核架构。

微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building

阅读全文

如何实现数据列优雅分页

入职新公司也有一段时间了,最近刚好主导了媒资库索引的构建,场景也主要集中在用户维度的查询,例如:用户个人主页媒资列表,用户在这些场景,一定程度上更希望有某一维度序列(时间/权重等)的溯源。
不同于个性化推荐的场景,用户在这里看到的内容需要有一定的顺序性,也就涉及到分页方案的选型,现在就以微博个人主页这个场景作为示例,咱们看看都有哪些比较有意思的方案。

数据库设计

这里以mysql为例,为了保持微博内容库的高效率,我们划分出单独的索引库来维护索引数据(用户ID与微博ID关系),其中索引库冗余一份内容状态,表结构如下

create table `weibo_index`(
    uid BIGINT NOT NULL DEFAULT 0 COMMENT '用户ID',
    mid VARCHAR(32) NOT NULL DEFAULT 
阅读全文

后端资源优化的一些小技巧

随着服务端流量的不断递增,对底层资源的依赖也越来越重,连接数增多,IO负载高等,很多性能瓶颈由此产生。下面主要谈谈DB/Redis/Mc这些核心资源的优化。

  1. DB DB的查询会触发磁盘IO,我们知道IO的代价是很高的,所以DB的优化主要从降低IO次数着手。

a. 优化慢查询 优化慢查询主要考虑从索引入手,众所周知,Innodb索引存储结构为B+树,真正的数据项只存在于叶子节点,所以要考虑降低树的查询长度,例如:有一表的列字段如下

`card` varchar(10) DEFAULT NULL,
UNIQUE KEY `idx_card` (`card`),
explain SELECT * FROM `table` WHERE 
阅读全文

后端的架构演进

1.互联网公司业务发展初期,没有较大流量,每日新增用户较少,技术团队核心点还是放在快速版本迭代,调研市场,开发新功能,以及配合一些活动、推广吸引新用户。所以业务初期,技术选型也比较简单。

对APP或WEB端来说,流量直接打到1台或多台ECS对应API,基于不同的业务场景,API会请求对应Nosql/缓存,或直接落到DB。

2.随着公司业务不断成型,用户的一步步累计,日活已经打到几十万甚至百万级别,初期的技术选型已经无法满足需求,ES及后端资源可能会频繁报警,这个时候就需要对已有的业务模型升级改造,由单机过渡到集群。

前端机会有SLB下的一组或多组ECS构成,SLB负责均衡外部流量,打到后端不同机器。对应的后端资源也会是主从集群模式,均衡单台CPU或内存过高而造成服务器无法响应。
除了资源的集群化,对应的业务也需要进行梳理改造,比如DB慢查,缓存、NoSQL滥用等等。
除此之外还要建立API及资源的安全化,比如API签名、加密,存储资源的有效期等等。
此阶段的主要任务是资源的合理化,减少对容易造成系统瓶颈资源的依赖,优化原有业务并制定新的开发规范,完善资源监控等等。

3.等到公司业务已经相对成熟,日活达到千万级别,市场良性循环建立,用户留存及新增用户都比较可观,这个时候架构升级就会偏向各个模块稳定性,后端各个模块会服务化,即微服务架构。

每个微服务模块相对隔离,有自己独立的一套资源(SLB, NOSQL, DB等),各个模块之间不会有过多耦合,最上层API会依据对应业务场景,组装或调用不同微服务模块。

此阶段的主要任务是保障可控,可监控、可扩展,减少模块之间相互依赖(包括逻辑依赖与资源依赖)。

各个微服务模块相对稳定之后,架构就要考虑平台化,比如账户体系,已经不单单是针对单一应用,要考虑SSO,OAuth等。媒资库也要考虑多端资源聚合等。

没有一成不变的架构,只有不断探索、优化,适当尝试新技术,才能打造一个稳定可靠的平台。 … 阅读全文