我要开花

前几年匆匆写了一系列的spring微服务入门课程. 当时主要用于总结心得和应付新团队的内部技术培训, 处于有点交差的心态, 很多点没有持续深入, 说老实话自己也不太满意. 两三年过去了, 现在我对微服务有更深入的认识, 业务知识也丰富了许多, 觉得自己是时候再写点深入的文章, 总结总结(加班)多年的心得了.

一开始打算命名这个系列叫做springcloud微服务中高级系列, 在写代码和心得的时候发现微服务的概念实在太大太广了, 遂打算挑一些主题, 针对主题慢慢写, 写细致, 写认真. 这样大家看得开心, 我在写的时候也能查漏补缺, 补上自己的不足.

开篇打算先写高并发系统.

网上的高并发系列文章已经很多了. 为了写出自己的特色, 我会以真实公司的业务和架构设计标准来写这些文章. 大家能看到小肥爬爬(真实姓名老陈, 昵称肥叔) 刚以架构师角色进入一家公司, 他接到了一个优化老架构和设计新架构的任务, 然后他会结合实际业务进行讨论, 给出设计方案和相应的权衡, 最后完成代码. 这些业务, 设计和代码都或多或少真实存在于各家公司. 所以这个系列不空谈, 不务虚, 打开代码就是干. 如果出现理论, 我会提个知识点或者放个链接, 大家可以自己去补理论知识.

当然作为一个小公司而非大厂的架构师, 我的视野和技术能力肯定还有许多不足, 如果看到什么太离谱的错误, 请大家指正.

正如之前的博客, 相关代码会放到gitee/github上, 希望这些个人认为挺有用的业务讨论和代码, 能够勾搭到读者的100个星星, 跪求了....

了解高并发概念与公司业务

云服务应用软件(系统)由于托管在互联网, 天然就带着"很可能有大量用户访问"的概率和概念. 因此各家招聘单位在给出自己的招聘岗位要求的时候, 大多带着"高流量, 高并发" 等字眼, 可是到底什么才是大流量, 什么才是高并发呢? 程序员要设计架构到什么程度, 才能满足要求? 程序员要具备什么样的知识, 才能不过度设计? (须知, 只要堆上硬件, 理论上99%的架构要求都能满足)

要回答高并发的这些问题和实际动手解决, 我认为程序员(架构师)要具备3个能力:

1. 了解掌握公司的业务, 推导, 预测, 设计测试, 探索公司的真实高并发需求.

2. 根据公司实际需求进行设计权衡, 裁剪云服务架构以适配公司业务的能力.

3. 在项目启动实际获得一定的流量数据之后, 总结, 优化, 提高架构瓶颈的能力.

以上都是小肥爬爬多年踩坑的心得, 一一解释如下.

挖掘公司真实的高并发需求

如果有家公司面试的时候问你: "我们日活用户有100万, 你怎么设计一个高并发系统? " 或者" 我们一天的交易流水有1000万, 你怎么设计一个高并发系统? " (这两个都是小肥爬爬真实的公司经验)

这时候可千万别被吓住! 这里面有一个老程序员显而易见的坑在等着你跳: 用户量和交易流水量都不代表着真正的高并发, 具体问题还是要具体分析. 那么怎么分析呢? 可以从两个维度进行出发: 技术指标和业务场景考虑.

技术指标: QPS/TPS/UV/PV

QPS: query per second (每秒读的数据). TPS: transaction per second (每秒完成事务的数据) . 这两个概念可以粗略分为读和写. 一般来说, 对于某个特定的介质或系统, 读的数据会远远大于写的数据. 这是一些关于读写数据的常识:

表格的第4行, 小肥爬爬让大家接触到熟悉的概念: 数据库. 以常用的mysql8 为例, 家用电脑的TPS大概在1-2000. 服务器版本的大概是级别呢? 一台阿里云 2核16G , 承诺 3-4000 TPS 的mysql版本数据库, 价格约 1500元/月. 这挺贵的价格也只有3,4000TPS, 这说明什么?

说明其实大多数公司业务的TPS都不高.

再来看看UV和PV. UV (user visited) 表示每天访问的用户数, PV(page visited) 表示用户所访问的总链接. 拿到系统的UV/PV数据, 再结合业务和代码, 就能把QPS和TPS大致摸出来了. 这也是业务分析的重要性, 单看一条访问请求, 不结合业务, 谁也不知道是TPS还是QPS.

业务场景分析

那么该公司什么样的业务场景会产生高qps和tps呢? 接下来小肥爬爬经过个人调研, 访谈, 查看合同, 阅读代码, 研究系统数据... 等方式, 逐渐了解新公司的业务. 原来该公司有2个主要产品: SAAS商场运营系统和四方支付系统. 前者主要为大客户服务, 大客户手下有员工, 并有自己的C端用户流量群体. 这些C端用户会使用SAAS的小程序进行支付 (暂时只有支付功能, 没有商城), 然后产生交易流水....

"哦对了", 老板最后轻飘飘加了一段: "下半年我们会上个商城, 会做秒杀功能, 你好好设计一下架构. "

费了九牛二虎之力, 小肥爬爬总算把业务需求澄清得七七八八. 最后他把业务场景归纳为以下几类:

架构师小肥爬爬经过周密的业务研究和分析之后, 成功地跳出了这个坑. 他不再是处于战争迷雾里两眼一黑的指挥官. 公司的一系列业务, 数据总量其实都不大, 瞬时流量也不大, 所以并发量并不大. 发现该公司唯一可能产生"高并发"请求的业务场景, 就是即将上线的商城秒杀任务了.

掌握了情报的小肥松了一口气, 开始下一阶段的架构设计工作.

程序员技巧: 如何迅速挖掘新系统的性能要求

1.用grep/sed命令, 统计nginx或者微服务的日志频率并排序, 找出top10-20 pv的接口. (如果运维环境有 prometheus 之类应用就更简单, 直接看数据即可. )

2.阅读该接口代码和查看数据库数据, 和业务人员讨论业务, 迅速了解该接口的业务背景.

最终目标, 是快速得出以下量化的性能数据分析表, 以做到心中有数, 并且可以和团队技术人员进行沟通.

image.png

(以上数据均有虚构, 如有雷同, 请联系我进行删除)

可以看出, 其实系统的QPS和TPS 均不高.

标准的云应用(微服务)架构

作为多年互联网开发老兵, 小肥爬爬此时已经知道, 公司的性能要求并不高, 标准的微服务架构就可以支撑. 即使未来上了秒杀业务, 稍加改造一些性能关键点即可. 但是作为程序员, 严谨是必须放在第一位的. 架构师必须给出明确的架构设计, 和各个部件的量化指标, 以作公司的技术要案备份和成为大家的讨论基础, 含糊其辞就干, 会让项目很容易陷入到忙乱和争吵之中. 比如这个技术该不该要? MQ该用哪个?服务器该买什么样的标准? 你做决定的依据是什么? ....

说到底, 努力用心, 经过详细分析设计的系统才是好系统, 才不会前期背负太多技术债务, 才容易随着业务演化而重构代码. 拍脑袋就上, 后期消灭不了代码屎山的项目, 老程序员已经见过好几个了.

裁剪微服务架构

image.png

小肥爬爬知道, 这是一个标准的微服务架构图, 可以说这个架构是万能的. 从业务系统开发 -> 数据仓库建设都一把完成了. 可是它也比较笨重, 需要维护的中间件也有点多. 之前说过架构师要懂得根据业务进行权衡, 那么前期没有数据仓库的时候, 是不是可以不用数据仓库的建设呢? 比如如果实际流量不大, 是否可以省个MQ? ... 诸如此类, 于是针对快要上线的商场秒杀功能, 他先做了个架构草图, 如下:

image.png

这是一个简单得不能再简单的"架构", 事实上就是后端网站的配置做法, 每个后端开发程序员入门学习的时候接触的都是这样的东西. 小肥爬爬需要作出说明的是: 如何进行业务设计, 才让这个架构满足公司的并发需求?

熟悉互联网开发的同学会发现, 其实这和单体结构没什么区别. 但是用微服务的好处, 就是后期扩展容易, 特别是业务分工更合理, 项目整体节奏加快. (当然也见过没有加快的案例, 那纯粹是团队能力问题了)

商城的秒杀指标

同时经过内部讨论, 历史数据研究, 后续业务数据预判, 业务需求讨论, 运营目标讨论.... 一系列动作, 小肥爬爬和他的团队制定了商城的数据指标:

1. 单次参与秒杀的商品数量不多于4000件. (业务方需求)

2. 要能支持最多10万用户并发抢单. (业务方和技术方妥协需求)

作为业务方来说, 能够支持越来越多的用户抢单当然好, 这能扩大产品的影响力; 可是作为技术方和已经掌握公司业务数据的小肥架构师, 这个饼不能无限地画大. 更多的用户意味着更多的服务器, 意味着更多的投入, 还可能误导团队做出过度的技术设计. 从已有数据来看, 小肥爬爬甚至觉得有一两万用户参加就不错了, 最终大家在友好的气氛中互殴, 啊不, 达成协议: 按照10万用户抢单来进行设计.

这是大多数软件公司的现状: 业务团队雄心勃勃但容易误导技术团队, 架构师要具备脚踏实地并适当前瞻的技术水平, 带领公司技术方向前进.

由于这篇教程的代码都是跑在本地而不是真实的多服务器生产环境, 所以我对目标略微作了一下调整. 调整成支持2000件商品参与秒杀, 1万用户参与并发. 这样已经足够作为代码演示了.

下一篇会正式开始撸代码.