架构师图谱·番外篇之研发效能

1. 如何理解研发效能

研发效能的完整定义应该是:团队能够持续地为用户产生有效价值的效率,包括有效性(Effectiveness)、效率(Efficiency)和可持续性(Sustainability)三个方面。简单来说,就是能否长期、高效地交付出有价值的产品。

在互联网行业内卷加剧的情况下,如何能更好的破局,而不是一味的推崇996,研发团队的效率就显得格外重要。开发流程的顺畅是生产优质软件的关键因素,只有这样才能最大程度地释放开发者的创造性和积极性,所以提高“研发效能”,我们更多的是围绕整个软件开发的生命周期,这里就不得不说一下“DevOps”和“云原生”。

2. DevOps

DevOps=Developers+Operators,字面上看,是指开发团队和运维团队一体化,通过工具辅助开发完成运维的部分工作,减少成本,尽可能地为公司创造更多价值。但是我们知道,任何一个产品或者项目从最初的需求意愿到最终的上线交付,中间不仅仅是只有开发、运维两两个角色就能完成,还包含产品、测试、QA、甚至商务、销售团队的人员共同参与才能完成。 因此在人们不断的实践过程中,DevOps逐渐扩展为整个软件研发过程的管理思想和方法论,它:​

  • 是一组过程、方法与系统的统称,包含开发、测试和运维;
  • 重视软件开发人员(Dev)和IT运维技术人员(Ops)之间沟通合作的文化、运动或惯例,改善团队之间的协作关系;
  • 用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合;
  • 透过自动化“软件交付”和“架构变更”的流程,使得构建、测试、发布软件能够更加地快捷、频繁和可靠,按时交付软件产品和服务;

DevOps在实施的过程中,往往是由最了解整个系统的开发人员来负责生命周期,包括自动化测试、线上服务观测,而传统的测试团队来为测试平台、工具提供支撑,运维(SRE)团队为运维平台、工具提供支撑。 DevOps其实就是通过打通Dev和Ops来提高研发效能,结合持续集成、持续交付、持续部署来提升交付效能。为了实现DevOps,除了团队协作、文化这些软性因素,更重要的是CI/CD流水线的建设。

2.1 CI/CD

CI/CD是指持续集成(Continuous Integration, CI)、持续交付(Continuous Delivery, … 阅读全文

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

1. 概述

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

1.1 序章

一个技术图谱:

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

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

完整的思维导图:

2. 微服务

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

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

阅读全文

Effective Go Plus

Effective Go》大家入门的时候一般都会去看,本篇属于Effective的“加强版”,主要聚焦在三个方向:

  1. runtime篇:常用数据结构及关键词的实现与实践
  2. 测试篇:测试的价值以及如何做单元测试和接口测试
  3. QA环节:技术转型中的思考

1. runtime篇

1.1 什么是runtime

runtime是go程序执行时使用的库,它控制着:

  1. slice, string, map, chan等数据类型以及反射的实现
  2. goroutine调度,内存分配,gc
  3. pprof, trace, race,
阅读全文

如何实现数据列优雅分页

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

数据库设计

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

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