程序员

程序员

86% 的Java开发者依赖它!Spring在Java领域占有统治地位

科技创新木土走召 发表了文章 • 0 个评论 • 109 次浏览 • 2021-05-25 15:58 • 来自相关话题

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。报告... ...查看全部

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!

就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。

报告中包含了各种调查,调查对象是随机抽取的全球450名程序猿,美国程序猿占比6成,剩余的是英国程序猿。而男女比例高达8:2,这里小编不尽嘀咕一句,有那么多女程序猿吗。。。

参与调查的程序猿普遍在35-44岁之间,可说都是精英程序猿。这些人都是使用Spring和其他框架的JAVA开发人员。原本计划预计大约60%来自Spring/Spring Boot,40%来自不使用Spring的人,但实际上大多数受访者都是Spring/Spring Boot的用户。450名受访者中,只有25人表示不使用Spring/Spring-Boot,另外38人不使用任何框架。 Spring比例高得惊人。

通过调查,发现Spring/Spring Boot 的开发者,往往比非 Spring 用户更重视单元测试,会比非Spring 用户多花费单元测试时间,达到25%,而非 Spring 用户这一数据只有20%。

同时Spring/Spring Boot 的开发者还倾向于拥有更高的代码质量和更可维护的代码,并在组织中拥有更好的代码覆盖率。(Spring框架的开发者有优秀代码能力的达54%,非Spring框架用户只有44%,无框架用户只有39%;单元测试覆盖率达到100%的都是Spring框架用户;同意单元测试让编写代码变得更简单的,Spring用户、其他框架用户、无框架用户分别是93%、88%、79%)

通过总结,报告对Spring/Spring Boot给出了5个特殊优点:

  • 核心技术(如Spring上下文、依赖注入等)

  • 测试支持

  • 数据存取

  • 与其他技术的集成(例如Hibernate)

  • 更容易设置web界面/API

而在这五个优点中,最受使用者青睐的是 更容易设置web界面/API(23.8%)和 测试支持(21.2%)

并且58%的Spring/Spring Boot用户说,Spring框架为开发人员节省了时间,54%的人认为他们的测试更快了,51%的人经历了更平稳的现代化。最后,49%的人说他们使用Spring/Spring Boot减少了开发者的摩擦,总之,意思就是Spring框架好处多多,谁用谁知道。

除了单元测试,在其他(非单元)测试上,花费时间的占比,Spring框架、其他框架、无框架分别是22.5%、21.8%、19.3%

和去年同期相比,使用Spring/Spring Boot的用户占比从60%提高到了86%,有显著的提升。

Spring使测试更容易的特性也使它更适合于独立开发者,这也有助于解释为什么所有被调查者所询问到Spring测试工具时,都被认为至少有点有用。例如,工具diffbluecover自动为Java代码编写单元测试。它对Spring用户尤其有效,因为Spring的标准化单元测试方式、内置模拟以及隔离被测单元和数据库依赖关系会让一切变得更加方便。

随着测试越来越被证实对开发的重要性,Spring/Spring Boot用户的增长也就只是时间的问题。


最蛋疼的注册中心与API网关实践?看了吐血!

科技创新王叫兽 发表了文章 • 0 个评论 • 122 次浏览 • 2021-05-25 15:58 • 来自相关话题

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与... ...查看全部

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与API网关的作用,并将它们用对地方!

在微服务架构中,我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制,集中的在API网关中进行统一管理,从而使得业务服务可以更加专注于业务领域本身。

而在微服务构建的系统内部,各个服务之间的调度,我们通常采用注册中心和客户端负载均衡的方式来实现服务之间的调用。

所以,大致的结构是这样子的:

在这样的架构实践中,注册中心和API网关的功能,主要有以下两点:

  1. API网关通过注册中心发现所有后端服务,从来实现动态代理

  2. 后端服务集群间,通过注册中心互相发现对方,而实现直接调用(通常使用Ribbon、Feign这些框架)

下面就来具体说说今天的主角(错误案例),先上图:

注意图中的两个地方:

  1. 存在两套网关,一套对内访问、一套对外访问

  2. 对内访问的网关实际就是起到了一个代理作用,较之前的图对比以下,就知道,这个方案中并没有利用到服务治理机制去直接让服务A调用服务B,而是通过网关去做了一次代理。

更令人震惊的是,在我看到代码的时候,他们居然也是用feign来编写服务间调用的,但在配置请求路径的时候,是使用在内部API网关上配置的二级域名来实现(比如:http://service-name.didispace.com/api-path,这里service-name对应不同的服务名),而熟悉Spring Cloud的读者都知道,其实service-name.didispace.com这部分直接用服务名替代就可以了…是不是瞬间有种脱裤子放x的感觉?

如果这样来使用的话,其实引入注册中心的用处就很小了,实际上只有给两个网关提供了集中的后端服务发现功能。如果要实现这种功能,其实注册中心都可以不需要,每个服务都直接上报地址给网关就好了,架构会更加简单。

同时,在这样的实现方式之下,内部调用都要经过内部网关多一跳的调度过程,除了要多出内部网关的部署资源之外,每一次内部调用的时间开销实际上都大了。所以这样的用法是非常不推荐的!

对于API网关的定位,还是以作为对外出口的管理为最佳,内部的代理调用,均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增加一层代理,不但增加部署成本,同时还会降低的性能。完全是赔了夫人又折兵的做法,非常不可取!

除非有一种情况,如果你的业务集群很大,对前端暴露用一套网关,同时后端服务有几千几万,由很多个不同的团队在维护,那么在团队的边界处设立内部的网关,那还是合理的。同时这种情况下,对于注册中心,按团队做隔离也是有必要的。因为这样可以分而治之,更好的做好接口的访问控制与管理。但是,如果你本身服务不多,团队也不大,那就别折腾这么复杂的架构了,越复杂稳定性就越难保障,这点一定要平衡好。


如何使用 Redis 实现一个轻量级的搜索引擎

科技创新fanta2 发表了文章 • 0 个评论 • 193 次浏览 • 2021-05-25 15:58 • 来自相关话题

场景大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。下面以一个例子开始,这是... ...查看全部

场景

大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。

下面以一个例子开始,这是某购物网站的搜索条件,如果让你实现这样的一个搜索接口,你会如何实现?(当然你说借助搜索引擎,像 Elasticsearch 之类的,你完全可以实现。但我这里想说的是,如果要你自己实现呢?)

从上图中可以看出,搜索总共分为6大类,每大类中又分了各个子类。这中间,各大类条件之间是取的交集,各子类中有单选、多选、以及自定义的情况,最终输出符合条件的结果集。

好了,既然需求很明确了,我们就开始来实现。

实现1

率先登场是小A同学,他是写 SQL 方面的“专家”。小A信心满满的说:“不就是一个查询接口吗?看着条件很多,但凭着我丰富的 SQL 经验,这点还是难不倒我的。”

于是乎就写出了下面这段代码(这里以 MYSQL 为例):select … from table_1left join table_2left join table_3left join (select … from table_x where …) tmp_1 …where …order by …limit m,n

代码在测试环境跑了一把,结果好像都匹配上了,于是准备上预发。这一上预发,问题就开始暴露出来。预发为了尽可能的逼真线上环境,所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL,它的执行效率可想而知。测试同学果断把小A的代码给打了回来。

实现2

总结了小A失败的教训,小B开始对SQL进行了优化,先是通过了explain关键字进行SQL性能分析,对该加索引的地方都加上了索引。同时将一条复杂SQL拆分成了多条SQL,计算结果在程序内存中进行计算。

伪代码如下:$result_1 = query(‘select … from table_1 where …’);$result_2 = query(‘select … from table_2 where …’);$result_3 = query(‘select … from table_3 where …’); …$result = array_intersect($result_1, $result_2, $result_3, …);

这种方案从性能上明显比第一种要好很多,可是在功能验收的时候,产品经理还是觉得查询速度不够快。小B自己也知道,每次查询都会向数据库查询多次,而且有些历史原因,部分条件是做不到单表查询的,所以查询等待的时间是避免不了的。

实现3

小C从上面的方案中看到了优化的空间。他发现小B在思路上是没问题的,将复杂条件拆分,计算各个子维度的结果集,最后将所有的子结果集进行一个汇总合并,得到最终想要的结果。

于是他突发奇想,能否事先将各个子维度的结果集给缓存起来,这要查询的时候直接去取想要的子集,而不用每次去查库计算。

这里小C采用 Redis 来存储缓存数据,用它的主要原因是,它提供了多种数据结构,并且在 Redis 中进行集合的交并集操作是一件很容易的事情。

具体方案,如图所示:

这里每个条件都事先将计算好的结果集ID存入对应的key中,选用的数据结构是集合(Set)。查询操作包括:

  • 子类单选:直接根据条件 key,获取对应结果集;

  • 子类多选:根据多个条件 Key,进行并集操作,获取对应结果集;

  • 最终结果:将获取的所有子类结果集进行交集操作,得到最终结果;

*这其实就是所谓的反向索引。*

这里会发现,漏了一个价格的条件。从需求中可知,价格条件是个区间,并且是无穷举的。所以上述的这种穷举条件的 Key-Value 方式是做不到的。这里我们采用 Redis 的另一种数据结构进行实现,有序集合(Sorted Set):

将所有商品加入 Key 为价格的有序集合中,值为商品ID,每个值对应的分数为商品价格的数值。这样在 Redis 的有序集合中就可以通过ZRANGEBYSCORE命令,根据分数(价格)区间,获取相应结果集。

至此,方案三的优化已全部结束,将数据的查询与计算通过缓存的手段,进行了分离。在每次查找时,只需要简单的查找 Redis 几次就能得出结果。查询速度上符合了验收的要求。

扩展

分页

这里你或许发现了一个严重的功能缺陷,列表查询怎么能没有分页。是的,我们马上来看 Redis 是如何实现分页的。

分页主要涉及排序,这里简单起见,就以创建时间为例。

如图所示:

图中蓝色部分是以创建时间为分值的商品有序集合,蓝色下方的结果集即为条件计算而得的结果,通过ZINTERSTORE命令,赋结果集权重为0,商品时间结果为1,取交集而得的结果集赋予创建时间分值的新有序集合。对新结果集的操作即能得到分页所需的各个数据:

  • 页面总数为:ZCOUNT命令

  • 当前页内容:ZRANGE命令

  • 若以倒序排列:ZREVRANGE命令

数据更新

关于索引数据更新的问题,有两种方式来进行。一种是通过商品数据的修改,来即时触发更新操作,一种是通过定时脚本来进行批量更新。这里要注意的是,关于索引内容的更新,如果暴力的删除 Key,再重新设置 Key。因为 Redis 中两个操作不会是原子性进行的,所以中间可能存在空白间隙,建议采用仅移除集合中失效元素,添加新元素的方式进行。

性能优化

Redis 是内存级操作,所以单次的查询会很快。但是如果我们的实现中会进行多次的 Redis 操作,Redis 的多次连接时间可能是不必要时间消耗。通过使用MULTI命令,开启一个事务,将 Redis 的多次操作放在一个事务中,最后通过EXEC来进行原子性执行(*注意:这里所谓的事务,只是将多个操作在一次连接中执行,如果执行过程中遇到失败,是不会回滚的 *)。

总结

这里只是一个采用 Redis 优化查询搜索的一个简单 Demo,和现有的开源搜索引擎相比,它更轻量,学习成本页相应低些。其次,它的一些思想与开源搜索引擎是类似的,如果再加上词语解析,也可以实现类似全文检索的功能。

转载于公众号“程序猿DD”

10大编程格言,作为程序员得你应该知道

科技创新木土走召 发表了文章 • 0 个评论 • 110 次浏览 • 2021-05-25 15:58 • 来自相关话题

每个程序员都该知道的10大编程格言(Kevin Pang):编程格言1:无风不起浪 (There is no smoke without fire)编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound ... ...查看全部

每个程序员都该知道的10大编程格言(Kevin Pang):

编程格言1:无风不起浪 (There is no smoke without fire)

编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound of cure:)

编程格言3:不要把鸡蛋都放在一个篮子(Don’t put all your eggs in one basket)

编程格言4:种瓜得瓜,种豆得豆(As you sow,so shoul you reap)

编程格言5:欲速则不达(Great haste makes great waste)

编程格言6:三思而后行( Look before you leap。Think first, Program later)

编程格言7:当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

编程格言8:沉默就是赞同 (Silence is construed as approval)

编程格言9:双鸟在林不如一鸟在手(A bird in the hand is worth two in the bush)

编程格言10:能力越大责任越大(With great power comes great responsibility)

1.无风不起浪(There is no smoke without fire):

设计糟糕的代码通常表现以下 的一些现象:

巨大的类或者方法

大区块注释的代码

重复的逻辑

过多 if/else 层次嵌套

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

Giant classes and/or functions

Large blocks of commented out code

Duplicated logic

Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term “code smoke” or “code fumes” is more appropriate as it implies a higher sense of urgency. If you don’t address the underlying problem it will come back to burn you later on.

2. 预防为主,治疗为辅(An ounce of prevention is worth a pound of cure)磨刀不误砍柴工

程序员经常错误地认为高效率编码就是快速编码,很多程序员不经思索和设计就直接编写代码。很不幸地是,这种 Leeroy Jenkins鲁莽做法将会编写出槽糕的代码,结果导致需要不断维护和修改代码,甚至有可能这些槽糕的代码将会被替换掉。因此,编码效率不仅以编码的时间,而且还有调试代码的时间。

捡了芝麻丢了西瓜。磨刀不误砍柴工。

原文:

Toyota’s assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn’t careful.

3. 不要把所有鸡蛋放在一个篮子 (Don’t put all your eggs in one basket)不要过度依赖某个人

一个软件项目开发团队的公共要素(bus factor)是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了,项目可能就会无序,甚至会搁置。

换言之,如果团队的关键成员突然流失,项目将会怎么办?业务仍继续还是停止呢?

因此我们在项目开发中, 每位开发人员最好能最熟悉软件系统非自己所擅长的部分。

原文:

A software team’s bus factor is defined as “the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed”.

In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into “domain experts” who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it’s unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when “domain experts” suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4.种瓜得瓜,种豆得豆 (As you sow, so shall you reap)

《注重实效的程序员》一书中有这样一段话解释“破窗理论”:

不要留着“破窗户”(不良的设计、错误的决策或者糟糕的代码)不修。发现一个就修一个。

如果没有足够的时间进行适当的修复,就先把它保留起来。或许你可 以把出问题的代码放到注释中,或是显示“未实现”消息,或用虚拟数据加以替代。采取一些措施,防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素(我们将在其他地方接触到),但(对“破窗”)置之不理,肯定会更快地加速系统崩溃。

简而言之,好的代码会促生好的代码,糟糕的代码也会促生糟糕的代码。别低估了习惯的力量。没人想去整理糟糕的代码,同样没人想把完美的代码弄得一团糟。写好你的代码,它才更可能经得住时间的考验。

原文:

The Pragmatic Programmer has this to say about the Broken Window theory:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

5 .欲速则不达(Great haste makes great waste)

经理、客户和程序员正日益变得急躁。一切都需要做的事,都需要马上就做好。正因如此,快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试?好吧,你可以先完成一次测试运行,然后你就可以随时回来继续测试它。

当访问Y属性时,会不会碰到奇怪的对象引用错误?无论怎样,把代码放到try/catch语句块中。我们要钓到大鱼啦!

是不是似曾相识呢?这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟,我们有最后期限,还得满足客户和经理。但不要过于频繁操 作,否则你会发现你的代码不稳定,有很多热修复、逻辑重复、未测试的方案和错误处理。最后,你要么是把事情草草做完,要么是把事情好好做完。

原文:

Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We’ve got bigger fish to fry!

Sound familiar? It’s because we’ve all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you’ll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

6. 三思而后行( Look before you leap)

“敏捷开发”这个词最近被频繁滥用,经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者,看到产品朝正当方向有实质进展,我们理应高兴。但意外的是,UML图和用例分析似乎并不能满足我们的愿望。所以,在不知自己做什么的情况下或者不知自己身处何处时,我们开发人员经常就稀里糊涂地写代码了。

这就好比你要去吃饭,但你根本没有想好去哪里吃。因为你太饿了,所以你迫不及待地找个餐馆,定个桌位。然后你上车开车后沿途在想(找地方吃饭)。只是,这样会耗费更多的时间,因为你要过较多的U型弯道,还在餐馆前停车,也许最后因等待时间过长而不吃了。确切地说,你最后应该能找到地方吃饭,但你可能 吃的饭并不是你想吃的,并且这样花费的时间,可能比你直接在想去的餐馆订餐所花的时间更长。

原文:

The term “Agile Development” is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don’t seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It’s like heading out for dinner when you haven’t yet decided where you want to go. You’re hungry so you don’t want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you’ll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you’ll probably find your way to food eventually, but you probably didn’t end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7.当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

看见了吧?我早就说过动态记录在这个项目中很有效

程序员有一种倾向,当一谈到他们工具时,其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”,我们就会在接下来所有的项目上都用到它。学习新东 西仿佛是一种煎熬,有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。

一定要摒弃这种想法,按我们所知道的去做,即使那不是最完美的解决方法。

坚持自己所知很简单,不过从长远的角度讲,选择一个适合这项工作的工具要容易得多。否则,就会与你的职业生涯格格不入。

原文:

See? I told you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools. Once something “just works” for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we’re thinking “it would have been easier had I just done it the old way!”. Enough of these moments and we will simply go with what we know, even if it isn’t a perfect fit for the task.

It’s easy to stick with what you know, but in the long run it’s much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. 沉默就是赞同(Silence is construed as approval)

我什么都没看见!没看见!

“破窗理论”与”变成惯性理论”有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多,就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码,那你每天都将和糟糕的代码相伴了。

同样地,如果你看到别人写出了糟糕的代码,你就要跟这个人提出来。注意,这时候机智就应该用上场了。一般情况下,程序员都愿意承认他们在软件开发中还是有不懂的地方,并且会感谢你的好意。互相帮助对大家都有利,而对问题视而不见,只会使问题一直存在。

原文:

I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale.

The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don’t make an effort to write good, clean,SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.

9.双鸟在林不如一鸟在手(A bird in the hand is worth two in the bush)

如果可以讨论系统架构和重构,那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动,权衡改动的利弊很重要。当然了,简洁是一个理想目标, 但总会有可以通过重构改进的代码。在编程世界中,为了代码不过时,会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么,你面临一个简单窘 境:你不能一石二鸟。你在重构旧代码上所发时间越多,你编写新代码的时间就越少。在及时改进代码和维护程序之间,也需要找到平衡点。

原文:

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It’s an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can’t do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10.能力越大责任越大(With great power comes great responsibility)

毫无疑问,软件已成为我们生活中一个既基本又重要的一部分。正因如此,开发优秀软件格外重要。乒乓球游戏中的Bug是一回事,航天飞机导向系统或者航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文,讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今天写的代码,无论你是否有意,说不定有朝一日在重要的应用程序中派上用场,这想想都令人害怕。编写正确合格的代码吧!

原文:

Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It’s one thing to have a bug in a game of Pong, it’s another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It’s a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.

Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!

转载于公众号:程序猿DD


SQL优化怎么做?来这里看看!

科技创新木土走召 发表了文章 • 0 个评论 • 137 次浏览 • 2021-05-25 15:58 • 来自相关话题

前言在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。SQL优化一般步骤1、通过慢查日志等定位那些执行效率较低的SQ... ...查看全部

前言

在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。

SQL优化一般步骤

1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划

需要重点关注type、rows、filtered、extra。

type由上至下,效率越来越高

  • ALL 全表扫描

  • index 索引全扫描

  • range 索引范围扫描,常用语<,<=,>=,between,in等操作

  • ref 使用非唯一索引扫描或唯一索引前缀扫描,返回单条记录,常出现在关联查询中

  • eq_ref 类似ref,区别在于使用的是唯一索引,使用主键的关联查询

  • const/system 单条记录,系统会把匹配行中的其他列作为常数处理,如主键或唯一索引查询

  • null MySQL不访问任何表或索引,直接返回结果 虽然上至下,效率越来越高,但是根据cost模型,假设有两个索引idx1(a, b, c),idx2(a, c),SQL为”select * from t where a = 1 and b in (1, 2) order by c”;如果走idx1,那么是type为range,如果走idx2,那么type是ref;当需要扫描的行数,使用idx2大约是idx1的5倍以上时,会用idx1,否则会用idx2

Extra

  • Using filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序,并按排序顺序检索行。

  • Using temporary:使用了临时表保存中间结果,性能特别差,需要重点优化

  • Using index:表示相应的 select 操作中使用了覆盖索引(Coveing Index),避免访问了表的数据行,效率不错!如果同时出现 using where,意味着无法直接通过索引查找来查询到符合条件的数据。

  • Using index condition:MySQL5.6之后新增的ICP,using index condtion就是使用了ICP(索引下推),在存储引擎层进行数据过滤,而不是在服务层过滤,利用索引现有的数据减少回表的数据。

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的,开启语句“set profiling = 1;”

SHOW PROFILES ;SHOW PROFILE FOR QUERY  #{id};
4、trace

trace分析优化器如何选择执行计划,通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

set optimizer_trace="enabled=on";set optimizer_trace_max_mem_size=1000000;select * from information_schema.optimizer_trace;
5、确定问题并采用相应的措施
  • 优化索引

  • 优化SQL语句:修改SQL、IN 查询分段、时间查询分段、基于上一次数据过滤

  • 改用其他实现方式:ES、数仓等

  • 数据碎片处理

场景分析

案例1、最左匹配

索引

KEY `idx_shopid_orderno` (`shop_id`,`order_no`)

SQL语句

select * from _t where orderno=''

查询匹配从左往右匹配,要使用order_no走索引,必须查询条件携带shop_id或者索引(shop_id,order_no)调换前后顺序

案例2、隐式转换

索引

KEY `idx_mobile` (`mobile`)

SQL语句

select * from _user where mobile=12345678901

隐式转换相当于在索引上做运算,会让索引失效。mobile是字符类型,使用了数字,应该使用字符串匹配,否则MySQL会用到隐式替换,导致索引失效。

案例3、大分页

索引

KEY `idx_a_b_c` (`a`, `b`, `c`)

SQL语句

select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;

对于大分页的场景,可以优先让产品优化需求,如果没有优化的,有如下两种优化方式, 一种是把上一次的最后一条数据,也即上面的c传过来,然后做“c < xxx”处理,但是这种一般需要改接口协议,并不一定可行。另一种是采用延迟关联的方式进行处理,减少SQL回表,但是要记得索引需要完全覆盖才有效果,SQL改动如下

select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;
案例4、in + order by

索引

KEY `idx_shopid_status_created` (`shop_id`, `order_status`, `created_at`)

SQL语句

select * from _order where shop_id = 1 and order_status in (1, 2, 3) order by created_at desc limit 10

in查询在MySQL底层是通过 n*m 的方式去搜索,类似union,但是效率比union高。in查询在进行cost代价计算时(代价 = 元组数 * IO平均值),是通过将in包含的数值,一条条去查询获取元组数的,因此这个计算过程会比较的慢,所以MySQL设置了个临界值(eq_range_index_dive_limit),5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200,即in条件超过了200个数据,会导致in的代价计算存在问题,可能会导致Mysql选择的索引不准确。

处理方式,可以(order_statuscreated_at)互换前后顺序,并且调整SQL为延迟关联。

案例5、范围查询阻断,后续字段不能走索引

索引

KEY `idx_shopid_created_status` (`shop_id`, `created_at`, `order_status`)

SQL语句

select * from _order where shop_id = 1 and created_at > '2021-01-01 00:00:00' and order_status = 10

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。(可以用到ICP)
select * from _order where shop_id=1 and order_status not in (1,2)select * from _order where shop_id=1 and order_status != 1

在索引上,避免使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小,则优化器还是会选择辅助索引,但是当访问的数据占整个表中数据的蛮大一部分时(一般是20%左右),优化器会选择通过聚集索引来查找数据。

select * from _order where  order_status = 1

查询出所有未支付的订单,一般这种订单是很少的,即使建了索引,也没法使用索引。

案例8、复杂查询
select sum(amt) from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01';select * from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01' limit 10;

如果是统计某些数据,可能改用数仓进行解决;如果是业务上就有那么复杂的查询,可能就不建议继续走SQL了,而是采用其他的方式进行解决,比如使用ES等进行解决。

案例9、asc和desc混用
select * from _t where a=1 order by b desc, c asc

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储,可能数据量会很大,如果在方案的选择上,最终选择存储在MySQL上,并且做7天等有效期的保存。那么需要注意,频繁的清理数据,会照成数据碎片,需要联系DBA进行数据碎片处理。

转载于公众号“程序猿”DD


【文末附PPT】融云2021 X-Meetup续航上海 以场景应用解析音视频技术新方向

技术活动admin 发表了文章 • 0 个评论 • 149 次浏览 • 2021-05-19 14:04 • 来自相关话题

2021年5月15日,融云X-Meetup技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”,由融云音视频研发高级工程师姜春雨、时光机器人创始人兼CEO徐晶、融云IM研发中心高级工程师刘佳、学而思网校架构师李亚龙,和资深音视频技术专家栗伟,五位技术大咖出... ...查看全部

2021年5月15日,融云X-Meetup技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”,由融云音视频研发高级工程师姜春雨、时光机器人创始人兼CEO徐晶、融云IM研发中心高级工程师刘佳、学而思网校架构师李亚龙,和资深音视频技术专家栗伟,五位技术大咖出任演讲嘉宾,他们以时下热门应用场景为视角,从技术实践出发,与开发者们交流分享了关于音视频技术新观察。微信图片_20210519115507.jpg

iOS 上的音频开发

今年,由于Clubhouse和Tiya的示范效应,语聊房产品大火,音频的开发技术备受开发者的关注。来自融云的音视频研发高级工程师姜春雨,多年专注于移动端和音视频领域的技术研发,他分享了《iOS 音频设备开发 - Core Audio》的主题内容。

微信图片_20210519115501.png

融云音视频研发高级工程师姜春雨发表演讲

姜春雨认为:移动端音频处理的难点在于声音美化、变声、实时高音质和场景玩法多样化。单从iOS设备来说,要突破这些难点,离不开iOS所提供的Audio Unit,它是一项强大灵活的音频处理技术,支持混合、均衡、格式转换和实时输入/输出,用于录制、播放、离线渲染和实时对话。

融云SDK以Audio Unit为基础,构建了长音效、短音效等多个功能模块,最终在音频设备上完成混音输出。在场景化实践中,姜春雨以音乐语聊房和百人超大会议室两个典型场景为例,分享了融云SDK的技术开发优化方案。比如,音乐语聊房注重高音质、美声变声,以舒适噪音为好,开发者要根据这些需求进行算法调优;而超大会议室的优化则要求做到服务端智能发流、多人声音同时出现可以智能选择会议发言人的声音。

姜春雨总结道:Audio Unit是一个强大的音频处理框架,音频处理要基于Audio Unit框架构建内容,并且要在音频处理内容上不断打磨优化。未来,融云音视频SDK还将不断基于不同场景需要开发新的功能,持续优化音频产品,为开发者提供更好的解决方案。

构建低延迟高可靠的信令系统

融云作为互联网通信云赛道的领先厂商,2020年在业界率先提出“IM+RTC+PUSH”的整体通信解决方案。融云RTC唤起用户的通道就是依赖于IM的SDK信令,因此,本次融云的IM研发中心高级工程师刘佳,分享了《构建低延迟高可靠信令系统的探索与实践》,帮助开发者更好地了解融云IM如何协同RTC,提供高可靠的通信能力。

微信图片_20210519115504.png

 融云IM研发中心高级工程师刘佳

刘佳介绍,高可靠音视频信令系统的构建在IM信令系统设计时,首先要进行服务分层,包括接入层、内部服务和数据存储的分层。而拆分原则要根据业务差异和服务对象的不同,拆分为API和 CMP,整体做到可监控、可维护。其次,是要搭建完整的监控体系,通过可视化的图表,监看网络的性能情况,及时处理系统瓶颈。

对于低延迟信令系统的实现,刘佳分享道,融云不仅利用全球加速网络,降低网络延迟,还基于融云自有通讯协议降低数据传输量,利用缓存机制,提高了服务的业务处理速度。并且,刘佳以缓存设计为例,说明通过一致性hash提高缓存命中率、高效利用CPU的处理能力、实施异步存储等,也都是实现低延迟系统设计的要旨。

基于这些设计要点,刘佳展示了海量并发用户场景下的语聊房系统架构,为开发者提供了干货解决方案。同时,他还总结出融云现有的音视频整体服务架构的三大优势:第一,信令服务与媒体服务解藕,两个服务之间也不需要状态同步;第二,媒体服务专注通信,信令服务专注能力;第三,部署简单,方便进行全球部署媒体服务。

直播系统架构设计 满足用户对实时性的需求

本场沙龙中,音视频直播场景也是一个重点话题。深耕互联网音视频12年,在直播领域积累了丰富实战经验的拾光机器人公司创始人兼 CEO徐晶,通过他的《互联网直播快速实战》,分享了基于直播答题场景的架构设计,尤其是几个关键技术点和应对策略,以及如何保证直播中的视频和音频质量,了详细的讲解。

沙龙中,专注于在线教育的学而思网校架构师李亚龙,还针对教育低延时大班的直播场景,为开发者带来了关于《在线教育直播系统架构升级》的分享。他着重从网校视频技术的发展、网校大班直播系统、网校公益直播课、低延迟直播探索这四个方面的设计要点,进行了分析讲解。对于专注在线教育的开发者而言,具有普遍的示范意义。

此外,资深音视频技术专家的栗伟,发表了《使用webrtc构建实时在线课堂》的演讲。栗伟曾任职于中科院计算所、CC视频,任职期间利用WebRTC技术开发了直播、在线课堂、视频会议等商业产品,并发用户数达到500万。他还曾主笔撰写了 《WebRTC技术详解:从0到1构建多人视频会议系统》,在该领域有多年实践经验,对WebRTC有非常深入的研究,他的实践分享让开发者们获益匪浅。

结语

在本次沙龙中,五位讲师的分享,其共性特点在于:他们都基于当下所关注热门场景展开话题。由此可见,应用场景才是“探讨音视频技术新方向”的基础,而越热门的场景往往越是代表着这个领域的发展潜力更大,因此也就越需要通过新技术、新产品加以承载。

随着5G的进一步落地,网络带宽、网络质量的不断优化,音视频通信无论在使用量级上,还是使用场景上,都会出现更多可能。对于开发者而言,只有及早储备,尽可能多地掌握新技术,关注新方向,才能赢在当下,赢在未来。

讲师PPT下载↓

0515演讲PPT.pdf

刷爆全网:一个中科大差生的8年程序员工作总结(上)

科技创新王叫兽 发表了文章 • 0 个评论 • 91 次浏览 • 2021-05-14 15:35 • 来自相关话题

今年终于从大菊花厂离职了,离职前收入大概 60w 不到吧!在某乎属于比较差的,今天终于有空写一下自己的职场故事,也算是给自己近 8 年的程序员工作做个总结复盘。近 8 年有些事情做对了,也有更多事情做错了,在这里记录一下,希望能够给后人一些帮助吧,也欢迎私信交... ...查看全部

今年终于从大菊花厂离职了,离职前收入大概 60w 不到吧!在某乎属于比较差的,今天终于有空写一下自己的职场故事,也算是给自己近 8 年的程序员工作做个总结复盘。

近 8 年有些事情做对了,也有更多事情做错了,在这里记录一下,希望能够给后人一些帮助吧,也欢迎私信交流。文笔不好,见谅,有些细节记不清了,如果有出入,就当是我编的这个故事吧。

PS:有几个问题先在这里解释一下,评论就不一一回复了

1.关于差生,我本人在科大时确实成绩偏下,差生主要讲这一点,没其他意思。

2.因为买房是我人生中的大事,我认为需要记录和总结一下,本文中会有买房,房价之类的信息出现,您如果对房价,炒房等反感的话,请您停止阅读,并且我再这里为浪费您的时间先道个歉。

2013 年
加入上海航天 x 院某卫星研究所

本人 86 年生人,13 年从中科大软件相关专业毕业,由于父母均是老师,从小接受的教育就是努力学习,找个稳定的“好工作”,报效国家。

于是乎,毕业时候头脑一热加入了上海航天 x 院某卫星研究所,没有经过自己认真思考,仅仅听从父母意见,就草率的决定了自己的第一份工作,这也为我 5 年后离职埋下了隐患。这里总结第一条经验:

如果你的亲人是普通阶层,那对于人生中一些大事来说,他们给的建议往往就是普通阶层的思维,他们的阶层就是他们一生思维决策的结果,如果你的目标是跳出本阶层,那最好只把他们的建议当成参考。

13 年 4 月份,我坐上火车来到上海,在一路换乘地铁来到了大闵行,出了地铁走路到单位,一路上建筑都比较老旧,我心里想这跟老家也没什么区别嘛,还大上海呢。

到达单位报道,负责报道的老师很亲切,填写完资料,分配了一间宿舍,还给了大概 3k 左右安家费,当时我心里那个激动啊(乡下孩子没有见过钱啊,见谅),拿了安家费,在附近小超市买好生活用品,这样我就开始了自己航天生涯。

经过 1 个月集中培训后,我分配到部门,主要负责卫星上嵌入式软件开发。不过说是高大上的卫星软件开发,其实刚开始就是打杂,给实验室、厂房推箱子搬设备,呵呵,说航天是个体力活相信很多航天人都有同感吧。不过当时年轻,心思很单纯,每天搬完设备,晚上主动加班,看文档材料,画软件流程图,编程练习,日子过得很充实。

记得第一个月到手大概 5k 左右(好少呀),当时很多一起入职的同事抱怨,我没有,我甚至不太愿意和他们比较工资,这里总结第二条经验:

不要和你的同事比工资,没有意义,比工资总会有人受伤,更多的是负面影响,并且很多时候受伤的会是你。

工作中暂露头角

工作大概一个月的时候,我遇到了一件事情,让我从新员工里面开始暂露头角。事情是这样的当时国家要对军工单位进行 GJB5000A 软件开发等级认证(搞过这个认证的同学应该都知道,过这个认证那是要多酸爽有多酸爽),但是当时一个负责配置管理的同事却提出离职,原因是他考上了公务员,当时我们用的那个软件平台后台的版本控制是 SVN 实现的,恰好我在学校写程序时用过,呵呵,话说回来现在学生自己写软件很少有人会在本地搭版本控制器吧!我记得当时还被同学嘲笑过,这让我想起了乔布斯学习美术字的故事,这里总结一下:

不要说一项技能没有用,任何你掌握的技能都有价值,但是你要学会找到发挥它的场景。如果有一天你落水了,你可能会很庆幸,自己以前学会了游泳。

工作中如果要上升,你要勇于承担麻烦的、有挑战的任务,当你推掉麻烦的时候,你也推掉了机遇。

好了,扯远了,回到前面,当时我主动跟单位认证负责人提出,我可以帮忙负责这方面的工作,我有一定经验。这里要提一下这个负责人,是位女士,她是我非常敬佩的一个前辈,认真,负责,无私,整个人为国家的航天事业奉献了几十年,其实航天领域有非常多这样的老前辈,他们默默奋斗,拿着不高的薪水,为祖国的国防建设做出了巨大的贡献。当时这位负责人,看我平时工作认真积极,思维反应也比较灵活(因为过认证需要和认证专家现场答辩的)就同意了我的请求,接受到这个任务之后,我迅速投入,学习认证流程、体系文件、迅速掌握认证工作要点,一点一点把相关的工作做好,同时周期性对业务进行复盘,总结复盘可能是我自己的一个优点:

很多人喜欢不停的做事,但不会停下来思考,缺乏总结复盘的能力,其实阶段性总结复盘,不仅能够固化前面的经验,也能梳理后面的方向;把事情做对很重要,但是更重要的是做对的事;另外不要贪快,方向正确慢就是快(后半句是我后来才想明白的,如果早想明白,就不会混成目前这样了)

1 个月后,当时有惊无险通过了当年的认证,当时负责人主动向单位申请了 2k 特别奖,当时我真的非常高兴,主要是自己的工作产生了价值,得到了认可。后来几个月的日子平淡无奇,有印象的好像只有两件事情。

一件事情是当年端午,当时我们在单位的宿舍休息,突然楼道上一阵骚动,我打开宿舍门一看,原来是书记来慰问,还给每个人送了一箱消暑饮料,这件事印象比较深刻,是我觉得国企虽然有各种各样的问题,但是论人文关怀,还是国企要好得多。

错失一次暴富的机会

另一件事是当年室友刚买房,然后天天研究生财&之道,一会劝我买房,一会劝我买比&特&币,我当时没有鸟他,为什么呢,因为当时的室友生活习惯不太好,会躺在床上抽烟,还在宿舍内做饭(我们宿舍是那种很老的单位房,通风不好),我有鼻炎,所以不是很喜欢他(嗯,这里要向室友道歉,当年真是太幼稚了)。现在 B&T&C4 万美元了,我当时要是听了室友也能小发一笔了(其实我后来 18 年买了,但是没有拿住这是后话),这里要总结一下:

不要因为某人的外在,如外貌、习惯、学历等对人贴上标签,去盲目否定别人,对于别人的建议,应该从客观出发,综合分析,从善如流是一项非常难得的品质。

人很难挣到他认知之外的财富,就算偶然拿到了,也可能很快失去。所以不要羡慕别人投机获得的财富,努力提升你的思维,财商才是正道。

航天生涯的第一个正式项目

转眼到了 9 月份(我 4 月份入职的),我迎来了我航天生涯第一个正式的型号项目(型号,是军工的术语,就相当于某个产品系列比如华为的 mate),当时分配给我的型号正式启动,我终于可以开始写卫星上的代码了。

当时真的是心无旁骛,一心投身军工码农事业,每天实验室,测试厂房,评审会,日子虽然忙碌,但是也算充实。并且由于我的努力工作,加上还算可以的技术水平,我很快就能独立胜任一些型号基础性的工作了,并且我的努力也受到了型号(产品)线的领导的认可,他们开始计划让我担任型号主管设计师,这是一般工作 1-2 年的员工的岗位,当时还是有的激动的。

2014 年
升任主管设计师后的一次波折

转眼间到 2014 年了,大概上半年吧,我正式升任主管设计师,研发工作上也开时独挡一面了,但是没多久产品研发就给了我当头一棒。

事情是这样的,当时有一个版本软件编写完毕,加载到整星上进行测试,有一天大领导来检查,当时非常巧,领导来时测试主岗按某个岗位的人员要求,发送了一串平时整星没有使用的命令(我在实验室是验证过的),结果我的软件立刻崩溃,无法运行。由于正好领导视察,这个问题立马被上报到质量处,于是我开始了苦逼的技术归零攻关(搞航天的都懂,我就不解释了)。

期间每天都有 3 个以上领导,询问进度,当时作为新人的我压力可想而知,可是我无论如何都查不出来问题,在实验室我的软件完全正常!后来,某天中午我突然想到,整星上可能有不同的环境,具体过程就不说了。后人查出来是一个负责加载我软件的第三方软件没有受控,非法篡改了我程序的 4 个字节,而这 4 字节正好是那天发送命令才会执行的代码,结果导致我的软件崩溃。最后我花了进一个月完成了所有质量归零报告,技术分析报告,当然负责技术的领导没有责怪,相反的还更加看重我了,后来我每遇到一个质量问题,无论多忙最后定要写一份总结分析报告,这成了我一个技术习惯,也为后来我升任软件开发组长奠定了技术影响基础。

强烈建议技术团队定期开展质量回溯,需要文档化,还要当面讲解,深入的技术回溯有助于增加团队技术交流活跃度,同时提升团队技术积淀,是提升产品质量,打造优秀团队的有效方法。

个人的话建议养成写技术总结文章的习惯,这不仅能提升个人技术,同时分享也可以增加你的影响力

职场软技能的重新认识

上半年就在忙碌中度过了,到了年底,发生了一件对我们组影响很大的事情,年底单位开展优秀小组评比, 其实这个很多公司都有,那为什么说对我们组影响很大内,这里我先卖关子。这里先不得不提一个人,是个女孩子,南京大学的,比我晚来一年,她做事积极,反应灵敏,还做得一手不错的 PPT,非常优秀,就是黑了点(希望她看到了不要来找我,呵呵)。

当时单位开展优秀小组评比,我们当时是新员工,什么都很新鲜,就想参加一下,当时领导说我们每年都参加的,我们问,我们每年做不少东西,怎么没有看到过评比的奖状,领导有点不好意思,说我们没有进过决赛。我们又问,多少名可以进入决赛圈,答曰前 27 名即可(总共好像 50+个组)我们当时心里真是一万个羊驼跑过。。。。

其实当时我们组每年是做不少事情的,我们觉得我们不应该排名如此之低,于是我们几个年轻人开始策划,先是对我们的办公室彻底改造(因为要现场先打分,然后进决赛),然后好好梳理了我们当年取得的成绩,现场评比时我自告奋勇进行答辩(我沟通表达能力还不错,这也算我一个优势吧),后面在加上前文提到的女孩子做的漂亮 PPT,最后我们组拿到了铜牌班组的好成绩,我也因为这次答辩的优秀表现在领导那里又得到了认可,写了大半段了,再总结一下:

职场软技能如自我展示很重要,特别是程序员,往往在这方面是个弱项,如果可以的话,可以通过练习,培训强化一下这些软技能,对职场的中后期非常有帮助。

2015 年

时间总是过得很快,一下就到 2015 年了,这一年发生了一件对我影响很大的事情。

升任小组副组长

当时我们小组有 18 个人了,有一天部门开会,主任要求大家匿名投票选副组长(当时部门领导还是很民主的),因为日常事务逐渐增多,老组长精力有限,想把一些事物分担出来,当天选举结果就出来了,我由于前面的技术积累和沟通表达能力的展现,居然升任副组长,当时即有些意外,因为总是有传言说国企没背景一辈子就是最最底层,后来我仔细思考过,下面是我不成熟的想法:

不要总觉得国企事业单位的人都是拼背景,拼关系,我承认存在关系户,但是不要把关系户和低能力挂钩,背景只是一个放大器,当关系户做出了成绩时它会正面放大影响,当关系户做了不光彩的事情是,它也会让影响更坏。没有背景,你可以作出更大的贡献来达到自己的目标,你奋斗的过程是更大的财富。另外,我遇到的关系户能力都很强,也可能是巧合,也可能是他们的父辈给给他们在经验层次上比我们更优秀的教育。

学习团队管理技巧

升任副组长后,我的工作更加忙碌了,不仅要做自己项目的事情,还要横向管理和协调组内其他项目的事情,有人说要多体谅军工单位的基层班组长,这话真是没错啊。这个时候我开始学习一些管理技巧,如何凝聚团队,如何统一协调资源等等,这段时间我还是在不断成长。不过记得当年还是犯了一个很大的方向性错误,虽然更多的原因可能归结为体制吧,但是当时其实可以在力所能及的范围内做一些事情的。

具体是这样的,当时管理上有项目线,有行政线,就是很常见的矩阵式管理体系,不过在这个特殊的体制下面出现了一些问题。当时部门一把手被上级强制要求不得挂名某个型号,因为他要负责部门资源调配,而下面的我们每个人都归属 1-2 个型号(项目),在更高层的管理上又有横向的行政线(不归属型号),又有纵向的型号管理线。

而型号的任务往往是第一线的,因为产品还是第一位的,但是个人的绩效、升迁又归属行政线管理,这种形式在能够高效沟通的民企或者外企一般来说不是问题,但是在沟通效率缓慢,还有其他掣肘因素的国企最终导致组内每个人忙于自身的型号任务,各自单打独斗,无法聚焦,一年忙到头最终却得不到部门认可,我也因为要两面管理疲于应付,后来曾经反思过,其实可以聚焦精力打造通用平台(虽然这在我们行业很难)部分解决这个问题:

无论个人还是团队,做事情要聚焦,因为个人和团队资源永远都是有限的,如果集中一个事情都做不好,那分散就更难以成功,但是在聚焦之前要深入思考,往什么方向聚焦才是正确的,只有持续做正确的事情才是最重要的。

2016 年

这一年是我人生的关键一年,发生了很多事情。

升任小组组长

第一件事情是我正式升任组长,由于副组长的工作经验,在组长的岗位上也做得比较顺利,在保证研发工作的同时,继续带领团队连续获得铜牌以上班组奖励,另外各种认证检查都稳稳当通过,但是就在这个时候,因为年轻,我犯下了一个至今非常后悔的错误。

大概是这样的,我们部门当时有两个大组,一个是我们的软件研发组,一个是负责系统设计的系统分析组。

当时两个组的工作界面是系统组下发软件任务书给软件组,软件组依照任务书开发,当时由于历史原因,软件组有不少 10 年以上的老员工,而系统组由于新成立由很多员工工作时间不到 2 年,不知道从什么时候起,也不知道是从哪位人员开始,软件组的不少同事认为自己是给系统组打工的。并且,由于系统组同事工作年限较短,实际设计经验不足,任务书中难免出现遗漏,从而导致实际产品出错,两组同事矛盾不断加深。

最后,出现了一个爆发:当时系统组主推一项新的平台,虽然这个平台得到了行政线的支持,但是由于军工产品迭代严谨,这个新平台当时没有型号愿意使用,同时平台的部分负责人,居然没有完整的型号经验!由于这个新平台的软件需要软件组实现,但是因为已经形成的偏见,软件同事认为这项工作中自己是为利益既得者打工。

我当时也因为即负责实际软件开发,又负责部分行政事务,并且年轻思想不成熟,也持有类似的思想。过程中的摩擦、冲突就不说了,最后的结果是系统组、软件组多人辞职,系统组组长离职,部门主任离职创业(当然他们辞职不全是这个原因,包括我离职也不全是这个原因,但是我相信这件事情有一定的影响),这件事情我非常后悔,后来反思过其实当时自己应该站出来,协调两组矛盾,全力支持部门技术升级,可能最终就不会有那么多优秀的同事离开了。

公司战略的转型,技术的升级迭代,一定会伴随着阵痛,作为基层组织者,应该摒弃个人偏见,带领团队配合部门、公司主战略,主战略的成功才是团队成功的前提。

买房

16 年我第二件大事情就是买房,关注过近几年房价的人都可能还记得,16 年一线城市猛涨的情景。其实当时 15 年底,上海市中心和学区房已经开始上涨,我 15 年底听同事开始讨论上涨的房价,我心里开始有了买房的打算,大约 16 春节(2 月份吧,具体记不得了),我回老家探望父母,同时跟他们提出了买房的打算。

我的父亲是一个“央视新闻爱好者”,爱好看狼咸平,XX 刀,XX 檀的节目,大家懂了吧,父亲说上海房价太高了,都是泡沫,不要买。这个时候我已经不是菜鸟了,我想起我总结的第一条经验(见上文),我开始收集往年的房价数据,中央历年的房价政策,在复盘 15 年的经济政策时我发现,当年有 5 次降息降准,提升公积金贷款额度,放松贷款要求于是我判定房价一定会继续涨,涨到一个幅度各地才会出台各种限购政策,并且房价在城市中是按内环往外涨的于是我开始第一次在人生大事上反对父母,我坚决表态要买房。父亲还是不太同意,他说年底吧,先看看情况(实际是年底母亲的退休公积金可以拿出来大概十几万吧,另外未来丈母娘的公积金也能拿出来了大概比这多些)。我还是不同意,父亲最终拗不过我,终于松口,于是我们拿着双方家庭凑的 50w 现金开始买房,后来上海的房价大家都看到了。这件事也是我做的不多的正确的事情之一。

但是最可笑的是,我研究房价的同时居然犯下了一个匪夷所思的错误,我居然没有研究买房子最重要的因素是什么,我们当时一心想买一手房(现在想想真是脑子进水),最后买了一套松江区交通不便的房子,这第一套房子的地理位置也为我后来第二次离职埋下了隐患,这个后面会说。

一线或者准一线城市能买尽量买,不要听信房产崩溃论,如果买不起,那可以在有潜力的城市群里用父母的名义先买一套,毕竟大多数人的财富其实是涨不过通货膨胀的。另外买房最重要的三个要素是,地段,地段,地段。

买房的那天上午和女朋友领的证,话说当时居然把身份证写错了三次 。。。

这下我终于算是有个家了,交完首付那个时候身上真的是身无分文了。航天的基层员工的收入真的是不高,我记得我当时作为组长,每月到手大概也就 7k-8k 的样子,另外有少量的奖金,但是总数仍然不高,好在公积金比较多,我日常也没什么消费欲望,房贷到是压力不大。

买完房子之后,我心里想,这下真的是把双方家庭都掏空了(我们双方家庭都比较普通,我的收入也在知乎垫底,没办法)万一有个意外怎么办,我思来想去,于是在我下一个月发工资之后,做了一个我至今也不知道是对是错的举动,我利用当月的工资,给全家人家人买了保险保险,各种重疾,意外都配好了。但是为什么我至今也不知道对错呢,因为后来老丈人,我母亲都遭遇病魔,但是两次保险公司都拒赔,找出的理由我真是哑口无言,谁叫我近视呢。另外真的是要感谢国家,亲人重病之后,最终还是走了医保,赔偿了部分,不然真的是一笔不小的负担。

2017 年

对我人生重大影响的 2016 年,在历史的长河中终究连浪花都激不起来。历史长河静静流淌到了 2017 年,这一年我参加了中国深空探测项目,当然后面我没有等到天问一号发射就离开了航天,但是有时候仰望星空的时候,想想我的代码正在遥远的星空发挥作用,心里也挺感慨的,我也算是重大历史的参与者了,呵呵。好了不说工作了,平淡无奇的 2017 年,对我来说也发生了两件大事。

买了第二套房子

第一件事是我买了第二套房子,说来可笑,当年第一套房子都是掏空家里,这第二年就买了第二套房子,生活真的是难以捉摸。到 2017 年时,前文说道,我母亲和丈母娘先后退休,公积金提取出来了,然后在双方家里各自办了酒席,酒席之后,双方父母都把所有礼金给了我们,父母对自己的孩子真的是无私之至。当时我们除了月光之外,其实没有什么外债,就是生活简单点。拿到这笔钱后,我们就在想如何使用,一天我在菜市场买菜,有人给我一张 xuanchuan 页,本来对于这样的 xuanchuan 页我一般是直接扔掉的,但是当天鬼死神差我看了一眼,只见上面写着“嘉善高铁房,紧邻上海 1.5w”我当时就石化了,我记得去年我研究上海房价的时候,曾经在网站上看到过嘉善的房价,我清楚的记得是 5-6k,我突然意识到我是不是错过了什么机会,反思一下:

工作生活中尽量保持好奇心,不要对什么的持怀疑态度,很多机会就隐藏在不起眼的细节中,比如二十年前有人告诉你未来可以在网上购物,有人告诉你未来可以用手机支付,你先别把他直接归为骗子,静下来想一想,凡事要有好奇心,但是要有自己的判断。

于是我立马飞奔回家,开始分析,大城市周边的房价。我分析了昆山,燕郊,东莞,我发现燕郊极其特殊,几乎没有产业,纯粹是承接大城市人口溢出,因此房价成高度波动。而昆山和东莞,由于自身有产业支撑,又紧邻大城市,因此房价稳定上涨。我和妻子一商量,开始了外地看房之旅,后来我们去了嘉善,觉得没有产业支撑,昆山限购,我们又到嘉兴看房,我发现嘉兴房价也涨了很多,但是这里购房的大多数新房,都是上海购房者,入住率比较低,很多都是打算买给父母住的,但是实际情况是父母几乎不在里面住,我觉得这里买房不妥,存在一个变现的问题。于是我开始继续寻找,一天我看着杭州湾的地图,突然想到,杭州湾北侧不行,那南侧呢?南侧绍兴,宁波经济不是更达吗。于是我们目光投向绍兴,看了一个月后,最后在绍兴紧贴杭州的一个区,购买了一套小房子,后来 17 年房价果然如我预料的那样完成中心城市的上涨之后开始带动三四线城市上涨。后来国家出台了大湾区政策,我对我的小房子更有信心了。这里稍微总结一下我个人不成熟的看法:

在稳定通胀的时代,负债其实是一种财富。长三角城市群会未来强于珠港澳,因为香港和澳门和深圳存在竞争关系,而长三角城市间更多的是互补,未来我们看澳门可能就跟看一个中等省会城市一样了。

准备要孩子

2017 年的第二件事是,我们终于准备要孩子了,但是妻子怎么也备孕不成功,我们开始频繁的去医院,从 10 元挂号费的普通门诊,看到 200 元,300 元挂号费的专家门诊,看到 600 元的特需门诊,从综合医院看到妇幼医院,从西医看到中医,每个周末不是在医院排队,就是在去医院的路上。最后的诊疗结果是有一定的希望,但是有困难,得到消息时我真的感觉眼前一片黑暗,这种从来在新闻上才能看到了事情居然落到了我们头上,我们甚至开始接触地下 XX 市场。同时越来越高的医疗开销(专家门诊以上就不能报销了)也开始成为了我的负担,前文说了,我收入一直不高,又还贷款,又支付医疗开支渐渐的开始捉襟见肘,我甚至动了卖小房子的打算。

未完待遇~

刷爆全网:一个中科大差生的8年程序员工作总结(下)

科技创新王叫兽 发表了文章 • 0 个评论 • 119 次浏览 • 2021-05-14 15:35 • 来自相关话题

2018 年前面说到,2017 年开始频繁出入医院,同时项目也越来越忙,我渐渐的开始喘不过气起来,最后医生也给了结论,需要做手术,手术有不小的失败的几率。我和妻子商量后一咬牙做吧,如果失败就走地下的路子,但是可能需要准备一笔钱(手术如果成功倒是花销不会太大),... ...查看全部
2018 年

前面说到,2017 年开始频繁出入医院,同时项目也越来越忙,我渐渐的开始喘不过气起来,最后医生也给了结论,需要做手术,手术有不小的失败的几率。我和妻子商量后一咬牙做吧,如果失败就走地下的路子,但是可能需要准备一笔钱(手术如果成功倒是花销不会太大),哎,古人说一分钱难倒英雄汉,真是诚不欺我啊,这个时候我已经开始萌生离职的想法了。怎么办呢,生活还是要继续,我想起了经常来单位办理贷款的银行人员,贷款吧,这种事情保险公司肯定不赔的嘛,于是我办理了一笔贷款,准备应急。

项目结束,离职

时间慢慢的时间走到了 8 月份,我的项目已经告一定段落,一颗卫星圆满发射成功,深空项目也通过了初样阶段我的第一份工作也算有始有终了。我开始在网上投递简历,我技术还算可以,沟通交流也不错,面试很顺利,一个月就拿到了 6 个 offer,其中就有大菊花厂的 offer,定级 16A,25k 月薪后来政策改革加了绩效工资 6k(其实我定级和总薪水还是有些偏低了和我是国企,本来总薪水就低有很大关系,话说菊花厂级别后面真的是注水严重,博士入职轻松 17 级)菊花厂的 offer 审批流程是我见过最长,我当时的接口人天天催于流程都走了近 2 个月。

我向领导提出了离职,离职的过程很痛苦,有过经历的人估计都知道,这里就不说了。话说我为什么会选择华为呢,一是当时急需钱,二是总觉得搞嵌入式的不到华为看看真的是人生遗憾。现在想想没有认真去理解公司的企业文化就进入一家公司还是太草率了:

如果你不认同一个公司的企业文化,你大概率干不长,干不到中高层,IT 人你不及时突破到中高层很快你就会面临非常多问题;公司招人主要有两种人,一种是合格的人,一种是合适的人,合格的人是指技能合格,合适的人是指认同文化。企业招人就是先把合格的人找进来,然后通过日日宣讲,潜移默化把不合适的人淘汰掉。

入职华为

经过一阵折腾终于离职成功,开始入职华为。离职我做了一件比较疯狂的事情,当时因为手上有一笔现金了,一直在支付利息,心里就像拿它干点啥。那时由于看病,接触了地下 XX 市场,听说了 B&TC,走之前我心一横买 B&T&C,后来不断波动,最终我还是卖了,挣了一些钱,但是最终没有拿到现在,果然是考验人性啊。

2019 年
成功转正

华为的试用期真长,整整 6 个月,每个月还有流程跟踪,交流访谈,终于我转正了,转正答辩我不出意料拿到了 Excellent 评价,涨了点薪水,呵呵还不错。华为的事情我不太想说太多,总之我觉得自己没有资格评判这个公司,从公司看公司的角度华为真正是个伟大的公司,任老爷子也是一个值得敬佩的企业家。

在华为干了半年后,我发现我终究还是入职的时候太草率了,我当时没有具体的了解这个岗位,这个部门。入职之后我发现,我所在的是硬件部门,我在一个硬件部门的软件组,我真是脑子秀逗了。

在一个部门,你需要尽力进入到部门主航道里,尽力不要在边缘的航道工作,特别是那些节奏快,考核严格的部门。

更严峻的是我所在的大组,居然是一个分布在全国 4 地的组,大组长(华为叫 LM)在上海,4 地各有一个本地业务负责人。我立刻意识到,到年终考评时,所有的成果一定会是 4 地分配,并且 4 地的负责人会占去一大部分,这是组织结构形成的优势。我所在的小组到时候会难以突破,资源分配会非常激烈。

备孕成功

先不说这些,在 18 年时妻子做完了手术,手术居然很成功。休息完之后我们 19 年初开始备孕了,这次真的是上天保佑,运气不错,很快就怀上了。这段时间,我虽然每天做地铁 1.5 小时到公司上班,经受高强度的工作,我心里每天还是乐滋滋的。但是,突然有一天,PL(华为小组长)根我说,LM 需要派人去杭研所支持工作,我是最合适人选,让我有个心里准备。当时我是不想去的,这个时候妻子是最需要关怀的时候,我想 LM 表达了我的意愿,并且我也知道如果去了杭州年底绩效考评肯定不高。过程不多说了,反正结果是我去了杭州。

于是我开始了两头奔波的日子,每个月回上海一趟。这过程中还有个插曲,家里老家城中村改造,分了一点钱,父母执意卖掉了老家学校周边的房子,丈母娘也处理老家的一些房子,然后把钱都给了我们,然后我用这笔家里最后的资产,同时利用华为的现金流在绍、甬不限购地区购买一些房子,我没有炒房的想法,只是防止被通货膨胀侵蚀而已,不过后来结果证明我貌似又蒙对了啊,我自己的看法是:

杭绍甬在经济层面会连成紧密的一片,在行政区上杭州兼并绍 部分区域的概率其实不大,行政区的扩展应该是先兼并自身的下级代管城市。

宝宝出生

不说房子了,继续工作吧。10 月份干了快一年时候,我华为的师傅(华为有师徒培养体系)偷偷告诉我被定为备选 PL 了,虽然不知道真假,但是我心里还是有点小高兴。不过我心里也慢慢意识到这个公司可能不是我真正想要的公司,这么多年了,愚钝如我慢慢也开始知道自己想干什么了。因为我的宝宝出生了,看着这只四脚吞金兽,我意识到自己已经是一个父亲了。

2019 年随着美国不断升级的制裁消息,我在华为的日子也走到年底,马上将迎来神奇的 2020 年。

2020

2020 就少写一些了,有些东西真的可能忘却更好。

在家办公

年初就给大家来了一个重击,新冠疫情改变了太多的东西。这个时候真的是看出华为的执行力,居家办公也效率不减多少,并且迅速实现了复工。到了 3-4 月份,华为开始正式评议去年绩效等级,我心里开始有预感,以前的分析大概率会兑现,并且绩效和收入挂钩,华为是个风险意识极强的公司,去年的制裁会导致公司开始风险预备,虽然我日常工作还是受到多数人好评,但是我知道这其实在评议人员那里,没有任何意义。果然绩效评议结果出来了,呵呵,我很不满意。绩效沟通时 LM 破例跟我沟通了很长时间,我直接表达了我的想法。LM 承诺钱不会少,呵呵,我不评价吧。后来一天开始组织调整,成立一个新的小组,LM 给我电话让我当组长,我拒绝了,这件事情我不知道对错,我当时是这样考虑的

  1. 升任新的职位,未必是好事,更高的职位意味着更高的要求,因此对备选人员要么在原岗位已经能力有余,要么时间精力有余;我认为当时我这两个都不满足,呵呵离家有点远,LM 很可以只是因为绩效事情做些补偿。

  2. 华为不会垮,这点大家有信心,但未来一定会出现战略收缩,最后这艘大船上还剩下哪些人不清楚,底层士兵有可能是牺牲品。

  3. 我 34 岁了

提出离职

另外我一直思考未来想做什么,已经有了一丝眉目,就这样,我拿了年终奖约 7 月就提出了离职,后来部门还让我做了最后一次贡献,把我硬留到 10 月份,这样就可以参加上半年考核了,让帮忙背了一个 C 呵呵,这是工作多年,最差绩效吧。

这里还有一个小插曲,最后这三个月我负责什么工作呢,因为 20 年 3 月开始我就接手了部分部门招聘工作(在华为干过的都知道为什么非 HR 也要帮忙招聘,呵呵大坑啊,就不多解释了),结果最后三个月我这个待离职员工居然继续负责招聘,真的是很搞笑,不过由于我在上一份工作中其实一直也有招聘的工作,所以也算做的轻车熟路,每天看 50 份左右简历(我看得都非常仔细,我害怕自己的疏忽会导致一个优秀的人才错失机会,所以比较慢)其实也蛮有收货,最后好歹对程序员如何写简历有了一些心得。

总结

好了 7 年多,近 8 年的职场讲完了,不管过去如何,未来还是要继续努力,希望看到这篇文章觉得有帮助的朋友,可以帮忙点个推荐,这样可能更多的人看到,也许可以避免更多的人犯我犯的错误。

把中国 14 亿人都拉到一个群,技术上能实现吗?

科技创新王叫兽 发表了文章 • 0 个评论 • 86 次浏览 • 2021-05-14 15:24 • 来自相关话题

“最近,知乎上有一个非常热门的问题:“把 14 亿中国人民都拉到一个微信群里在技术上能实现吗?”实际上,根据国家统计局的数据,截至 2017 年末,中国大陆总人口为 13 亿 9008 万人(包括 31 个省、自治区、直辖市和中国人民解放军现役军人,不包括香港... ...查看全部

“最近,知乎上有一个非常热门的问题:“把 14 亿中国人民都拉到一个微信群里在技术上能实现吗?”

实际上,根据国家统计局的数据,截至 2017 年末,中国大陆总人口为 13 亿 9008 万人(包括 31 个省、自治区、直辖市和中国人民解放军现役军人,不包括香港、澳门和台湾以及海外华侨人数),早已超过 13 亿。

目前,微信群组成员人数上限为 500 人,把近 14 亿中国人都拉到一个微信群,从技术的角度考虑现实吗?需要多少台服务器?

而且在一个 14 亿人的群里,要怎样抢红包?手机会不会爆炸?欢迎大家收看官方吐槽系列~

根据 2017 年《微信数据报告》的公开数据 [参考 1] : 2017 年 9 月,微信日均登录 9.02 亿人,日均发送消息 380 亿次。

这意味着平均每人每天发送信息 42 条,如果全国人民(对了,现在全国人口已经接近 14 亿)在同一个群里说话,这个群每天出现的信息就高达:

这么多信息仅仅是匀速发送的话,考虑到大家的睡眠,睡觉的 8 小时不算,那么手机里每秒要接收的信息就是:

哇塞,每秒超过 100 万条啊!目前主频最高的手机 CPU 之一,高通骁龙 845有 2.8GHz 的处理能力[参考 2] ,一共是 8 核。

如不计算安卓系统、显示刷新、网络 IO 等 CPU 操作的话,每条信息能分配到的计算能力是:

这是什么概念?全球第一款微处理器是 1971 年英特尔推出的 Intel 4004[参考 3],这个老古董的主频也有 108KHz 啊。所以 21.9KHz 就是啥也干不了。

幸好 IT 界有个摩尔定律: 每 18 个月 CPU 性能就能翻倍(或者价钱是一半)。虽然现有科技已经很难让主频提升(某牙膏厂拼命挤也只有 5 Ghz)。

但假设我们使用了黑科技提升主频。等到了 2025 摩尔定律失效时[参考 4],我们的手机 CPU 主频应该达到:

看起来不错嘛,不过每条消息能得到的计算能力将达到:

呵呵,依然没有达到 Intel 4004 的水平,所以结果就是你等了 7 年,还是进不了这个全国群抢一个红包。

好吧,咱们让手机接入一个给力点的电脑, 比如说全球超算第一名的太湖之光,1 千万个 CPU 核心 [参考 5] 来帮忙处理这个宇宙第一大微信群。算力的问题总算有了着落。

我们假设平均每条消息有 10 个汉字,这大概相当于 30 byte,算上应用层会加上一定的控制字符,再加上 TCP/IP 网络层的数据消耗大概是 74 byte,取个整,平均每条消息有 100 byte,每个 byte 相当于 8 个 bit。

这时每秒需要的网络带宽大约是:

如果有人发红包,需要的带宽就更大了。

理论上,4G 网络能支持 1000 Mbps[参考 6],但别忘了,是全国人民在同一个群里,而你周围的人也需要同样的带宽,这使得你附近的基站不堪重负,陷入瘫痪。

为了避免网络瘫痪导致你抢不到红包或者看群消息,你需要搬到一个周围没有人的基站,比如放暑假了全校只有你还没回家的时候。

不过运营商的日子就不好过了,因为这一秒全国上下的流量就达到了惊人的:

这相当于 2017 年 4 月份的全国移动数据总流量的 65.7%[参考 7],意味着每 18 秒就能用完全国一年的流量。运营商瑟瑟发抖.gif

如果把 1.146 Ebit 数据用 2TByte 3.5 英寸硬盘(20 mm 高)装起来,然后叠起来,有 1433.25 m,相比之下,全球最高楼——迪拜的哈里发塔只有区区 828m。

当然,如果确实有需要,我相信电信运营商们肯定砸下重金为你建设全世界最大的宽带网络。

不过,接下来该花钱的就不是运营商——而是腾讯了。

为了处理这 1.146 Ebps 的流量, 腾讯需要准备 11466 万套交换机和服务器。

目前一台大厂 4 口万兆交换机售价大约是 4000 元,一台便宜带万兆口的服务器则大概需要 10000 元,这两项加起来的费用是:

呃,仅仅这两项就相当于 深圳 2014 年全年的 GDP[参考 8]。

这里还不包括网线、电线、服务器机架、机房托管、电费、运行支出……

这么多设备的存放也是个问题。一台带万兆(10Gbps)口的 2U 服务器有 88.9 mm 高,这样叠起来就有:

这差不多是中国到美国的飞机航线距离啊,用来修铁路也是够够的了。

好了,有了这么多设备加持,这下你终于可以愉快地进了群。

但你惊讶地发现,屏幕上除了白色,什么都没有——这是因为你的眼睛没办法接收这么快的数据!

人眼的视觉暂留时间是 100-400 毫秒[参考 9] ,而我们这个群每秒钟就要显示 102 万条信息,每条消息停留的时间只有大概 0.001 毫秒。相比之下,电影、电视都有 41 毫秒。

因此你还没来得及看清消息,它就已经消失了,最后只留下一团白色的色块在屏幕的正中央。

网友留言:

@大哥有柔情:

14 亿在一个群并不可怕。可怕的是,每逢节日群里都会让群主发红包!

@后知后觉:

已经做到了,14 亿人拉到一个微信群,大家看到的都是新闻联播。

@bluecat:

简单的说,你的手机会马上崩溃,因为它承载不了一秒钟的信息量。

@三毛鱼

可以实现,不过要加几条限制:

①所有微信账号强制加入到这个微信群。

②微信群只能有限的几个人发言,其他人不能发言。

③微信群里只能在每天固定时间段发消息。

④其他微信群在固定时间不能发消息,或者只能转发这个微信群的消息。

这样就可以实现了,技术上没有难度。

@程墨Morgan

“拉”到一个群里没啥不难实现的,反正用户信息都在服务器上,建一个包含所有用户微信号的群也就是添加一个记录而已。

但是,这个群千万不要让任何人都能发言,就以我国人民的多样性,各种话唠、贴图狂人、广告狂人……海量信息瞬间就可以把服务器、运营商网络和你手机的电池击溃。

@世安先生

讲真,单从理论上来说目前的技术还是可行的,咳咳,我要装逼了。

看了别的答主的回答,说人、终端、传输、处理、存储、分析等等各方面均有缺陷或者短板,跟不上大批量的数据,其实个人觉得实施起来也还是有得搞的,只是成本和利润之间的关系罢了。

首先,得考虑人的因素,多少多少亿的信息量对于某个特定个体来说价值无限接近于 0,我个人根本不关注这些信息,因为获取信息的效率太低了。

这就导致了百分之九十九的人直接忽略了这个群的存在,剩下的每天这个群里的消息无非就是置顶公告,置顶新闻,红包和闲聊斗图,浏览公告和新闻。

考虑到并发的问题,一般现在的服务器都可以做到,毕竟有大把的新闻 App 都可以做到;红包,做个算法随机分配吧,也别抢了,抢会严重影响体验,给十亿用户随机分配一段数据应该难度也不太大。

剩下的就是斗图闲聊,数据直接云存储在服务器端,分析处理总结出来个中心思想每多少秒多少秒推送给个人用户一次,就差不多了,需要详细信息的上服务器检索,个人觉得对个人终端的压力也不会太大。

其次,传输,这是我觉得问题最小的一个环节,为什么呢?解决了个人终端的问题之后,个人的数据传输量并不大,现有的传输网络完全可以满足。

服务器端的传输,要看这服务器怎么个建法,如果集中式处理和存储,就只能用百 G 专线,建个三五条完全够了。

只不过相应的配套交换机路由器要建一套庞大的系统出来。如果是分布式存储和处理,10G 的甚至 GE 的专线都够。这是传输。

第三,处理,如果非得把大批量的数据集中处理,就得建设一套国内最大甚至世界最大最复杂的数据中心才能够承载这套系统。

但是如果分布式处理的话,我相信现在的系统也够用,毕竟现有的运算量已经这么大了,而有这个群之后数据量也绝对不会爆炸式增长。

第四,存储,处理的工作能够完成存储肯定也不是问题,甚至可以将数据破碎后存储在个人终端上,将投资设备的矛盾转嫁到数据安全和管理上。

第五,数据分析,这一点才是重中之重,难点中的难点,如何有效的分析提取如此大量数据中的有用信息并推送给特定的个人才是核心关键。

虽然现在技术还没有大面积商业化,但我相信这种技术是肯定已经有试用的甚至是已经商用的存在了,只不过公众不太清楚而已,毕竟这种东西仔细想想还是有点恐怖的。

总之,如何实现这个系统或者说建好这个群,无非就是做好需求与资源之间矛盾的转嫁,把存储需求量大与投资大之间的矛盾转嫁到数据安全与运营管理上,把大数据量传输分散化,把大量的数据进行分析提取后定向推送,最核心的投资也就是整套智能有效的大数据分析系统。

(ಥ_ಥ)不过……话说这么搞的话不就是搞了个有 14 亿关注量的公众号嘛…d(ŐдŐ๑)好了,我装逼装完了,你们打的时候下手轻点,别拿砖头,别提 40 米青龙偃月大关刀……

转载于公众号“程序猿DD”


北京云中融信网络科技有限公司(简称融云),是安全、可靠的全球互联网通信云服务商,向开发者和企业提供即时通讯和实时音视频通信云服务。iResearch 艾瑞权威数据报告显示,融云即时通讯云市场份额连续多年稳居头位。

融云构建了一张覆盖全球所有国家及地区(共 233 个)的通信云网络,在全球各地设立多个数据中心及数千个加速节点。基于客户业务需求,融云可提供多种部署模式——公有云、私有云、混合云,为全球企业提供稳定的互联网通信云服务。针对企业级用户,融云将业务垂直到各个行业,为社交、直播、金融、交通运输、教育、电商、医疗等多个行业领域推出了针对性解决方案。

融云基于海量业务的技术锤炼,从基础架构到精细化运营,充分体现平台实力;凭借卓越的产品和优质的服务,在开发者规模、行业覆盖率、平台日活跃用户数、日均消息量等方面超越全行业。目前,已有数十万互联网用户及上千家企业级用户通过融云实现了场景化沟通,并从中获益,包括工商银行、中国移动、四川航空、CCTV 微视、中联重科、58 赶集、大河报业、新东方、陆金所、融创地产、IDG、华兴资本、易车网、猪八戒、得到 APP、荔枝、汽车之家、哈啰出行、百姓网、StarMaker、Opera、Elelive。

重大消息!Apache下这些与Hadoop相关的开源项目要退休了!

科技创新王叫兽 发表了文章 • 0 个评论 • 68 次浏览 • 2021-05-14 15:24 • 来自相关话题

不知不觉之间,小编发现 Apache下许多与Hadoop相关的开源项目竟然都要退休了!包括像Sentry、Tajo和Falcon在内的13个与大数据相关的Apache项目,相继在11天之内宣布退出。不得不说一句,看起来Hadoop和大数据的美好时代就... ...查看全部

不知不觉之间,小编发现 Apache下许多与Hadoop相关的开源项目竟然都要退休了!

包括像Sentry、Tajo和Falcon在内的13个与大数据相关的Apache项目,相继在11天之内宣布退出。

不得不说一句,看起来Hadoop和大数据的美好时代就要正式结束了。

Apache Hadoop曾经是大数据的招牌产品,虽然大家都知道其现在已经过了鼎盛时期。但自4月1日以来,Apache软件基金会(ASF)已经宣布至少19个开源项目退出,其中13个与大数据相关,10个是Hadoop生态系统的一部分。还是让人感到乍舌。

也许单独一个项目的退出不会让人觉得是回事,但陆陆续续这么多项目一同退出,似乎就成了一个由盛转衰的分水岭,小编整理了下这13个与大数据相关的已退出的Apache项目。

  • Apex:基于Hadoop的大数据流和批处理的统一平台

  • Chukwa:一个用于监视大型分布式系统的数据收集系统,建立在Hadoop分布式文件系统(HDFS)之上

  • Crunch:它为编写、测试和运行MapReduce(包括Hadoop MapReduce)管道提供了一个框架

  • Eagle:一种分析解决方案,用于在大数据平台(包括Hadoop)上即时发现安全和性能问题

  • Falcon:Hadoop的数据处理和管理解决方案,用于数据移动、数据管道协调、生命周期管理和数据发现

  • Hama:一个大数据分析框架,运行在Hadoop上,基于批量同步并行范式

  • Lens:提供了一个统一的分析接口,它将Hadoop与传统的数据仓库集成在一起,看起来就像一个

  • Marmotta: 链接数据的开放平台

  • Metron:专注于实时大数据安全

  • PredictionIO:用于管理和部署生产就绪预测服务的机器学习服务器

  • Sentry:在Apache Hadoop中对数据和元数据实施细粒度授权的系统

  • Tajo:一个基于Hadoop的大数据仓库系统

  • Twill,它使用Hadoop YARN的分布式功能和类似于运行线程的编程模型

除了小编整理的这些项目,其实还有很多其他项目一并退出了。但最引人注意的还是在这不到两周时间里宣布退出的13巨头。

对于这个现象事件,官方又是怎么说的呢?

Apache软件基金会(ASF)的营销和宣传的副总裁Sally Khudairi,在其回复的电子邮件中提到:

Apache项目活动在其整个生命周期中起起落落,这取决于社区的参与程度。每一个退出的项目都是经过项目管理委员会和董事会反复斟酌投票之后的决定。

同时他表示这仅仅是常规项目退出的激增,但我们可以发现在开源领域,Hadoop已经让位于Spark ,像Hortonworks和旧Cloudera之间毫无意义的项目复制已经越来越少。

同样明显的是,大量投资Apache Sentry 的供应商和客户现在需要开始考虑他们的损失,以及下一步的前进方向。其实每一个技术的兴起和冷落都有类似的炒作周期,技术热门、开源激增、生态系统建立,然后直到他被其他新技术取代。

转载于公众号:程序猿DD

一起爬山吗?如果张东升是个程序员

好玩创意梅川酷子 发表了文章 • 0 个评论 • 498 次浏览 • 2020-07-08 10:28 • 来自相关话题

我就问你怕不怕!张东升是一家互联网公司的程序员,一直以来都勤勤恳恳老实工作。可最近一段时间,老板接了几个项目回来,不但开启了996的工作模式,更要命的是频频更改需求,弄得大家是敢怒不敢言。时间一久,东升慢慢开始消极怠工,晚上也不怎么加班了。终于有一天,和老板在... ...查看全部

我就问你怕不怕!

1.jpg

张东升是一家互联网公司的程序员,一直以来都勤勤恳恳老实工作。
可最近一段时间,老板接了几个项目回来,不但开启了996的工作模式,更要命的是频频更改需求,弄得大家是敢怒不敢言。
时间一久,东升慢慢开始消极怠工,晚上也不怎么加班了。终于有一天,和老板在会议室吵了起来,老板决意让其忙完手头的项目就离职。
老板看大家最近一段时间都很辛苦,决定组织一次团建,在群里询问大家有什么活动建议。
这时,张东升提议:“最近大家都工作挺累,也没有什么机会锻炼,身体要紧,要不一起去爬六峰山吧”
东升的提议获得了不少人的赞同,团建活动就这么定了下来。
团建这天,爬至半山腰,东升问老板:“您看我还有机会吗?”
2.png
老板看了他一眼,没有说话,继续抽烟。
爬至山顶,大家三三两两都在拍照发朋友圈。
这时东升拉住老板到一旁说给他拍照,老板知道东升是为讨好自己,也就没有拒绝。
东升举起手机,却说老板衣服有褶皱,上前为其整理,竟趁其不备将其推下山崖···

晚上,张东升还在电脑前调试着代码,突然,一封主题为“警告”的邮件窗口从侧边弹了出来。
东升的心跳立刻加速,小心翼翼的点开了这封邮件,正文只有四个字:“请看附件”
附件是一个word文档,东升并没有立即打开,职业习惯让他打开了VMware虚拟机,在虚拟机中打开了这个文件。
原来以为白天的事无人知晓,没想到这一幕正好被对面山头正在拍摄抖音短视频的三个小孩用手机录了下来。
三个小孩看到了张东升T恤上的公司名字,并在公司网站上找到了他的邮箱,这才给他发了这封邮件。
张东升看到后,大惊失色,想找到对方,却不知道对方是什么来头。
这时他注意到附件是一个docx文件,想到office2007及其以后的版本才用这个格式,其实际上是一个压缩文件格式zip。
东升思索片刻将其重命名为一个zip文件,然后解压,想看看是否能发现些什么信息。
3.png
接着在docProps目录下找到了app.xml:
...
<AppVersion>15.0000</AppVersion>
...
版本号是15,看来对方用的是一个Office2013版本的word。
东升很快在网络上搜到了一个漏洞:CVE-2017-11882,这是一个可以远程执行代码的漏洞,字符串拷贝没有对长度进行校验导致栈溢出。
说干就干,东升打开了metasploit,通过它很快生成一段包含恶意代码的word文件,将其作为附件回复给了对方。
三个小孩此刻正聚集在朱朝阳的家里,自从他们发送了警告邮件,心里就忐忑难耐,一直盯着电脑屏幕,看看是否会有回复。
一看到邮件弹窗,就赶紧点了开来。邮件正文也只写了一句话:我想说的都在附件中。
朱朝阳没有犹豫,又立刻点了附件。电脑上的Word进程随即启动,解析附件doc文件时,触发了漏洞,执行了张东升事先编写的恶意代码。而此时,朱朝阳却一无所知。
4.png
恶意程序很快和张东升的电脑建立了网络连接,并开始收集朱朝阳电脑的信息,IP地址、MAC地址、电脑文件等等。
东升不愧是经验丰富的程序员,为了躲过电脑防火墙的拦截,他编写的恶意代码通过ICMP协议的负载字段进行数据传输。
朱朝阳正瞅着空白的word文档感到疑惑,突然电脑屏幕上出现了一个视频聊天窗口,一陌生男子的画面突然出现吓得朱朝阳惊出了一身冷汗。
定睛一看,这男子不是别人,正是推人的张东升。
张东升先开口了:“没想到竟然是个小孩。我已经知道你电脑的IP地址,也知道你家住在哪里,明天上午出来聊聊,就在你家巷子口的面馆。”,说完就切断了视频信号。
张东升的突然出现,显然吓坏了朱朝阳。一旁的严良问到:“什么是IP地址?他又是怎么知道你家的位置,连面馆都知道,这简直太可怕了。”
朱朝阳镇定了两分钟,缓过神来,说到:“一定是刚才的邮件附件有问题,我的电脑已经被他控制。IP地址是电脑接入网络分配的通信身份证号码,通过IP地址就能锁定电脑的位置,再用地图一看就能知道附近的街道布局和街景画面,知道面馆也就不足为奇了”
这一夜注定是个不眠之夜。
第二天,双方如约相见。张表示可以用钱买下手机,严良威胁张东升,要卖可以,必须30万。
东升愣了一下,“你们小小年纪,要这么多钱做什么?”
严良顶了一句:“不关你的事”
东升无奈,表示要先看到手机视频再说。
朱朝阳拿出手机,刚打开视频,手机竟然没电。张见状拿出自己手机的充电器给朱朝阳。
待手机充电,张看到了视频。张表示他一个程序员,挣得不多,要等到四月份发了年终奖才凑得齐。
三小孩却只给了他一个星期时间。
一个星期过去,见东升未曾联系,三小孩主动联系张。张却不以为意,说让他们去报警吧。
三小孩不解,正想拿着手机去报警,却发现手机竟然已经死机无法打开了。
原来张东升拿出的那个充电器是事先精心准备,充电器里面内置了一个小型芯片,数据线一旦连接到手机就植入病毒程序,等待时机进行手机数据破坏。
5.png
不过,让张东升没有想到的是,朱朝阳竟然提前备份了数据,再次发来邮件威胁。
夜晚,洗完澡的张东升看着镜子里在自己,回想这些年多少次熬夜加班,不记得何时竟已经秃头,戴上了假发。
6.png
怒从心中起,恶向胆边生。张东升决定把这三个小孩一并收拾了。
东升跟踪数日,终于找到另外两个小孩原来住在海边浅滩的破船上,一天夜里洒满汽油纵火焚烧。
随即又潜到朱朝阳的住处,竟发现虽然已是深夜,朱朝阳还在电脑旁写着代码,旁边的书桌上放满了C/C++编程、数据结构与算法、操作系统等书籍。不禁想起了当年挑灯学习编程的自己。没想到一失足成千古恨,如今自己再也回不了头了。
不知何故,张东升竟改变主意,悄然离开了。
第二天,张向朱朝阳的电子邮箱里发送了一份学习资料,什么剑指offer、分布式计算、云计算、微服务、Dubbo、高并发、数据库实战,琳琅满目,应接不暇,足足有100多G。
不久,海边纵火一事案发,警方通过在电信局部署的网络流量采集中心的木马警报日志,溯源恢复了之前的邮件来往信息,很快锁定了程序员张东升。
张东升再次来到朱朝阳家,挟持了朱,警方随后赶到。
朱问张:你杀了我的小伙伴,为什么却给我发了一堆学习资料?
张东升笑着说:“杀了你有什么意思,我要你像我一样,成为一个程序员。”
朝阳却说:“那你干嘛给我放网盘,100多G的资料,60KB/s,你知道要下多久吗?”
东升一听大怒,举起手中利器便要作势刺向朝阳,只听一声枪响,东升应声倒下。


转自:Python技术之巅(公众号:PythonPeak)

作者:轩辕之风

产品经理在我手里,一个赞捏一下

回复

好玩创意梅川酷子 回复了问题 • 2 人关注 • 1 个回复 • 327 次浏览 • 2020-08-31 18:41 • 来自相关话题

86% 的Java开发者依赖它!Spring在Java领域占有统治地位

科技创新木土走召 发表了文章 • 0 个评论 • 109 次浏览 • 2021-05-25 15:58 • 来自相关话题

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。报告... ...查看全部

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!

就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。

报告中包含了各种调查,调查对象是随机抽取的全球450名程序猿,美国程序猿占比6成,剩余的是英国程序猿。而男女比例高达8:2,这里小编不尽嘀咕一句,有那么多女程序猿吗。。。

参与调查的程序猿普遍在35-44岁之间,可说都是精英程序猿。这些人都是使用Spring和其他框架的JAVA开发人员。原本计划预计大约60%来自Spring/Spring Boot,40%来自不使用Spring的人,但实际上大多数受访者都是Spring/Spring Boot的用户。450名受访者中,只有25人表示不使用Spring/Spring-Boot,另外38人不使用任何框架。 Spring比例高得惊人。

通过调查,发现Spring/Spring Boot 的开发者,往往比非 Spring 用户更重视单元测试,会比非Spring 用户多花费单元测试时间,达到25%,而非 Spring 用户这一数据只有20%。

同时Spring/Spring Boot 的开发者还倾向于拥有更高的代码质量和更可维护的代码,并在组织中拥有更好的代码覆盖率。(Spring框架的开发者有优秀代码能力的达54%,非Spring框架用户只有44%,无框架用户只有39%;单元测试覆盖率达到100%的都是Spring框架用户;同意单元测试让编写代码变得更简单的,Spring用户、其他框架用户、无框架用户分别是93%、88%、79%)

通过总结,报告对Spring/Spring Boot给出了5个特殊优点:

  • 核心技术(如Spring上下文、依赖注入等)

  • 测试支持

  • 数据存取

  • 与其他技术的集成(例如Hibernate)

  • 更容易设置web界面/API

而在这五个优点中,最受使用者青睐的是 更容易设置web界面/API(23.8%)和 测试支持(21.2%)

并且58%的Spring/Spring Boot用户说,Spring框架为开发人员节省了时间,54%的人认为他们的测试更快了,51%的人经历了更平稳的现代化。最后,49%的人说他们使用Spring/Spring Boot减少了开发者的摩擦,总之,意思就是Spring框架好处多多,谁用谁知道。

除了单元测试,在其他(非单元)测试上,花费时间的占比,Spring框架、其他框架、无框架分别是22.5%、21.8%、19.3%

和去年同期相比,使用Spring/Spring Boot的用户占比从60%提高到了86%,有显著的提升。

Spring使测试更容易的特性也使它更适合于独立开发者,这也有助于解释为什么所有被调查者所询问到Spring测试工具时,都被认为至少有点有用。例如,工具diffbluecover自动为Java代码编写单元测试。它对Spring用户尤其有效,因为Spring的标准化单元测试方式、内置模拟以及隔离被测单元和数据库依赖关系会让一切变得更加方便。

随着测试越来越被证实对开发的重要性,Spring/Spring Boot用户的增长也就只是时间的问题。


最蛋疼的注册中心与API网关实践?看了吐血!

科技创新王叫兽 发表了文章 • 0 个评论 • 122 次浏览 • 2021-05-25 15:58 • 来自相关话题

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与... ...查看全部

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与API网关的作用,并将它们用对地方!

在微服务架构中,我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制,集中的在API网关中进行统一管理,从而使得业务服务可以更加专注于业务领域本身。

而在微服务构建的系统内部,各个服务之间的调度,我们通常采用注册中心和客户端负载均衡的方式来实现服务之间的调用。

所以,大致的结构是这样子的:

在这样的架构实践中,注册中心和API网关的功能,主要有以下两点:

  1. API网关通过注册中心发现所有后端服务,从来实现动态代理

  2. 后端服务集群间,通过注册中心互相发现对方,而实现直接调用(通常使用Ribbon、Feign这些框架)

下面就来具体说说今天的主角(错误案例),先上图:

注意图中的两个地方:

  1. 存在两套网关,一套对内访问、一套对外访问

  2. 对内访问的网关实际就是起到了一个代理作用,较之前的图对比以下,就知道,这个方案中并没有利用到服务治理机制去直接让服务A调用服务B,而是通过网关去做了一次代理。

更令人震惊的是,在我看到代码的时候,他们居然也是用feign来编写服务间调用的,但在配置请求路径的时候,是使用在内部API网关上配置的二级域名来实现(比如:http://service-name.didispace.com/api-path,这里service-name对应不同的服务名),而熟悉Spring Cloud的读者都知道,其实service-name.didispace.com这部分直接用服务名替代就可以了…是不是瞬间有种脱裤子放x的感觉?

如果这样来使用的话,其实引入注册中心的用处就很小了,实际上只有给两个网关提供了集中的后端服务发现功能。如果要实现这种功能,其实注册中心都可以不需要,每个服务都直接上报地址给网关就好了,架构会更加简单。

同时,在这样的实现方式之下,内部调用都要经过内部网关多一跳的调度过程,除了要多出内部网关的部署资源之外,每一次内部调用的时间开销实际上都大了。所以这样的用法是非常不推荐的!

对于API网关的定位,还是以作为对外出口的管理为最佳,内部的代理调用,均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增加一层代理,不但增加部署成本,同时还会降低的性能。完全是赔了夫人又折兵的做法,非常不可取!

除非有一种情况,如果你的业务集群很大,对前端暴露用一套网关,同时后端服务有几千几万,由很多个不同的团队在维护,那么在团队的边界处设立内部的网关,那还是合理的。同时这种情况下,对于注册中心,按团队做隔离也是有必要的。因为这样可以分而治之,更好的做好接口的访问控制与管理。但是,如果你本身服务不多,团队也不大,那就别折腾这么复杂的架构了,越复杂稳定性就越难保障,这点一定要平衡好。


如何使用 Redis 实现一个轻量级的搜索引擎

科技创新fanta2 发表了文章 • 0 个评论 • 193 次浏览 • 2021-05-25 15:58 • 来自相关话题

场景大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。下面以一个例子开始,这是... ...查看全部

场景

大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。

下面以一个例子开始,这是某购物网站的搜索条件,如果让你实现这样的一个搜索接口,你会如何实现?(当然你说借助搜索引擎,像 Elasticsearch 之类的,你完全可以实现。但我这里想说的是,如果要你自己实现呢?)

从上图中可以看出,搜索总共分为6大类,每大类中又分了各个子类。这中间,各大类条件之间是取的交集,各子类中有单选、多选、以及自定义的情况,最终输出符合条件的结果集。

好了,既然需求很明确了,我们就开始来实现。

实现1

率先登场是小A同学,他是写 SQL 方面的“专家”。小A信心满满的说:“不就是一个查询接口吗?看着条件很多,但凭着我丰富的 SQL 经验,这点还是难不倒我的。”

于是乎就写出了下面这段代码(这里以 MYSQL 为例):select … from table_1left join table_2left join table_3left join (select … from table_x where …) tmp_1 …where …order by …limit m,n

代码在测试环境跑了一把,结果好像都匹配上了,于是准备上预发。这一上预发,问题就开始暴露出来。预发为了尽可能的逼真线上环境,所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL,它的执行效率可想而知。测试同学果断把小A的代码给打了回来。

实现2

总结了小A失败的教训,小B开始对SQL进行了优化,先是通过了explain关键字进行SQL性能分析,对该加索引的地方都加上了索引。同时将一条复杂SQL拆分成了多条SQL,计算结果在程序内存中进行计算。

伪代码如下:$result_1 = query(‘select … from table_1 where …’);$result_2 = query(‘select … from table_2 where …’);$result_3 = query(‘select … from table_3 where …’); …$result = array_intersect($result_1, $result_2, $result_3, …);

这种方案从性能上明显比第一种要好很多,可是在功能验收的时候,产品经理还是觉得查询速度不够快。小B自己也知道,每次查询都会向数据库查询多次,而且有些历史原因,部分条件是做不到单表查询的,所以查询等待的时间是避免不了的。

实现3

小C从上面的方案中看到了优化的空间。他发现小B在思路上是没问题的,将复杂条件拆分,计算各个子维度的结果集,最后将所有的子结果集进行一个汇总合并,得到最终想要的结果。

于是他突发奇想,能否事先将各个子维度的结果集给缓存起来,这要查询的时候直接去取想要的子集,而不用每次去查库计算。

这里小C采用 Redis 来存储缓存数据,用它的主要原因是,它提供了多种数据结构,并且在 Redis 中进行集合的交并集操作是一件很容易的事情。

具体方案,如图所示:

这里每个条件都事先将计算好的结果集ID存入对应的key中,选用的数据结构是集合(Set)。查询操作包括:

  • 子类单选:直接根据条件 key,获取对应结果集;

  • 子类多选:根据多个条件 Key,进行并集操作,获取对应结果集;

  • 最终结果:将获取的所有子类结果集进行交集操作,得到最终结果;

*这其实就是所谓的反向索引。*

这里会发现,漏了一个价格的条件。从需求中可知,价格条件是个区间,并且是无穷举的。所以上述的这种穷举条件的 Key-Value 方式是做不到的。这里我们采用 Redis 的另一种数据结构进行实现,有序集合(Sorted Set):

将所有商品加入 Key 为价格的有序集合中,值为商品ID,每个值对应的分数为商品价格的数值。这样在 Redis 的有序集合中就可以通过ZRANGEBYSCORE命令,根据分数(价格)区间,获取相应结果集。

至此,方案三的优化已全部结束,将数据的查询与计算通过缓存的手段,进行了分离。在每次查找时,只需要简单的查找 Redis 几次就能得出结果。查询速度上符合了验收的要求。

扩展

分页

这里你或许发现了一个严重的功能缺陷,列表查询怎么能没有分页。是的,我们马上来看 Redis 是如何实现分页的。

分页主要涉及排序,这里简单起见,就以创建时间为例。

如图所示:

图中蓝色部分是以创建时间为分值的商品有序集合,蓝色下方的结果集即为条件计算而得的结果,通过ZINTERSTORE命令,赋结果集权重为0,商品时间结果为1,取交集而得的结果集赋予创建时间分值的新有序集合。对新结果集的操作即能得到分页所需的各个数据:

  • 页面总数为:ZCOUNT命令

  • 当前页内容:ZRANGE命令

  • 若以倒序排列:ZREVRANGE命令

数据更新

关于索引数据更新的问题,有两种方式来进行。一种是通过商品数据的修改,来即时触发更新操作,一种是通过定时脚本来进行批量更新。这里要注意的是,关于索引内容的更新,如果暴力的删除 Key,再重新设置 Key。因为 Redis 中两个操作不会是原子性进行的,所以中间可能存在空白间隙,建议采用仅移除集合中失效元素,添加新元素的方式进行。

性能优化

Redis 是内存级操作,所以单次的查询会很快。但是如果我们的实现中会进行多次的 Redis 操作,Redis 的多次连接时间可能是不必要时间消耗。通过使用MULTI命令,开启一个事务,将 Redis 的多次操作放在一个事务中,最后通过EXEC来进行原子性执行(*注意:这里所谓的事务,只是将多个操作在一次连接中执行,如果执行过程中遇到失败,是不会回滚的 *)。

总结

这里只是一个采用 Redis 优化查询搜索的一个简单 Demo,和现有的开源搜索引擎相比,它更轻量,学习成本页相应低些。其次,它的一些思想与开源搜索引擎是类似的,如果再加上词语解析,也可以实现类似全文检索的功能。

转载于公众号“程序猿DD”

10大编程格言,作为程序员得你应该知道

科技创新木土走召 发表了文章 • 0 个评论 • 110 次浏览 • 2021-05-25 15:58 • 来自相关话题

每个程序员都该知道的10大编程格言(Kevin Pang):编程格言1:无风不起浪 (There is no smoke without fire)编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound ... ...查看全部

每个程序员都该知道的10大编程格言(Kevin Pang):

编程格言1:无风不起浪 (There is no smoke without fire)

编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound of cure:)

编程格言3:不要把鸡蛋都放在一个篮子(Don’t put all your eggs in one basket)

编程格言4:种瓜得瓜,种豆得豆(As you sow,so shoul you reap)

编程格言5:欲速则不达(Great haste makes great waste)

编程格言6:三思而后行( Look before you leap。Think first, Program later)

编程格言7:当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

编程格言8:沉默就是赞同 (Silence is construed as approval)

编程格言9:双鸟在林不如一鸟在手(A bird in the hand is worth two in the bush)

编程格言10:能力越大责任越大(With great power comes great responsibility)

1.无风不起浪(There is no smoke without fire):

设计糟糕的代码通常表现以下 的一些现象:

巨大的类或者方法

大区块注释的代码

重复的逻辑

过多 if/else 层次嵌套

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

Giant classes and/or functions

Large blocks of commented out code

Duplicated logic

Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term “code smoke” or “code fumes” is more appropriate as it implies a higher sense of urgency. If you don’t address the underlying problem it will come back to burn you later on.

2. 预防为主,治疗为辅(An ounce of prevention is worth a pound of cure)磨刀不误砍柴工

程序员经常错误地认为高效率编码就是快速编码,很多程序员不经思索和设计就直接编写代码。很不幸地是,这种 Leeroy Jenkins鲁莽做法将会编写出槽糕的代码,结果导致需要不断维护和修改代码,甚至有可能这些槽糕的代码将会被替换掉。因此,编码效率不仅以编码的时间,而且还有调试代码的时间。

捡了芝麻丢了西瓜。磨刀不误砍柴工。

原文:

Toyota’s assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn’t careful.

3. 不要把所有鸡蛋放在一个篮子 (Don’t put all your eggs in one basket)不要过度依赖某个人

一个软件项目开发团队的公共要素(bus factor)是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了,项目可能就会无序,甚至会搁置。

换言之,如果团队的关键成员突然流失,项目将会怎么办?业务仍继续还是停止呢?

因此我们在项目开发中, 每位开发人员最好能最熟悉软件系统非自己所擅长的部分。

原文:

A software team’s bus factor is defined as “the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed”.

In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into “domain experts” who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it’s unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when “domain experts” suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4.种瓜得瓜,种豆得豆 (As you sow, so shall you reap)

《注重实效的程序员》一书中有这样一段话解释“破窗理论”:

不要留着“破窗户”(不良的设计、错误的决策或者糟糕的代码)不修。发现一个就修一个。

如果没有足够的时间进行适当的修复,就先把它保留起来。或许你可 以把出问题的代码放到注释中,或是显示“未实现”消息,或用虚拟数据加以替代。采取一些措施,防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素(我们将在其他地方接触到),但(对“破窗”)置之不理,肯定会更快地加速系统崩溃。

简而言之,好的代码会促生好的代码,糟糕的代码也会促生糟糕的代码。别低估了习惯的力量。没人想去整理糟糕的代码,同样没人想把完美的代码弄得一团糟。写好你的代码,它才更可能经得住时间的考验。

原文:

The Pragmatic Programmer has this to say about the Broken Window theory:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

5 .欲速则不达(Great haste makes great waste)

经理、客户和程序员正日益变得急躁。一切都需要做的事,都需要马上就做好。正因如此,快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试?好吧,你可以先完成一次测试运行,然后你就可以随时回来继续测试它。

当访问Y属性时,会不会碰到奇怪的对象引用错误?无论怎样,把代码放到try/catch语句块中。我们要钓到大鱼啦!

是不是似曾相识呢?这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟,我们有最后期限,还得满足客户和经理。但不要过于频繁操 作,否则你会发现你的代码不稳定,有很多热修复、逻辑重复、未测试的方案和错误处理。最后,你要么是把事情草草做完,要么是把事情好好做完。

原文:

Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We’ve got bigger fish to fry!

Sound familiar? It’s because we’ve all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you’ll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

6. 三思而后行( Look before you leap)

“敏捷开发”这个词最近被频繁滥用,经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者,看到产品朝正当方向有实质进展,我们理应高兴。但意外的是,UML图和用例分析似乎并不能满足我们的愿望。所以,在不知自己做什么的情况下或者不知自己身处何处时,我们开发人员经常就稀里糊涂地写代码了。

这就好比你要去吃饭,但你根本没有想好去哪里吃。因为你太饿了,所以你迫不及待地找个餐馆,定个桌位。然后你上车开车后沿途在想(找地方吃饭)。只是,这样会耗费更多的时间,因为你要过较多的U型弯道,还在餐馆前停车,也许最后因等待时间过长而不吃了。确切地说,你最后应该能找到地方吃饭,但你可能 吃的饭并不是你想吃的,并且这样花费的时间,可能比你直接在想去的餐馆订餐所花的时间更长。

原文:

The term “Agile Development” is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don’t seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It’s like heading out for dinner when you haven’t yet decided where you want to go. You’re hungry so you don’t want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you’ll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you’ll probably find your way to food eventually, but you probably didn’t end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7.当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

看见了吧?我早就说过动态记录在这个项目中很有效

程序员有一种倾向,当一谈到他们工具时,其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”,我们就会在接下来所有的项目上都用到它。学习新东 西仿佛是一种煎熬,有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。

一定要摒弃这种想法,按我们所知道的去做,即使那不是最完美的解决方法。

坚持自己所知很简单,不过从长远的角度讲,选择一个适合这项工作的工具要容易得多。否则,就会与你的职业生涯格格不入。

原文:

See? I told you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools. Once something “just works” for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we’re thinking “it would have been easier had I just done it the old way!”. Enough of these moments and we will simply go with what we know, even if it isn’t a perfect fit for the task.

It’s easy to stick with what you know, but in the long run it’s much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. 沉默就是赞同(Silence is construed as approval)

我什么都没看见!没看见!

“破窗理论”与”变成惯性理论”有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多,就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码,那你每天都将和糟糕的代码相伴了。

同样地,如果你看到别人写出了糟糕的代码,你就要跟这个人提出来。注意,这时候机智就应该用上场了。一般情况下,程序员都愿意承认他们在软件开发中还是有不懂的地方,并且会感谢你的好意。互相帮助对大家都有利,而对问题视而不见,只会使问题一直存在。

原文:

I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale.

The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don’t make an effort to write good, clean,SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.

9.双鸟在林不如一鸟在手(A bird in the hand is worth two in the bush)

如果可以讨论系统架构和重构,那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动,权衡改动的利弊很重要。当然了,简洁是一个理想目标, 但总会有可以通过重构改进的代码。在编程世界中,为了代码不过时,会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么,你面临一个简单窘 境:你不能一石二鸟。你在重构旧代码上所发时间越多,你编写新代码的时间就越少。在及时改进代码和维护程序之间,也需要找到平衡点。

原文:

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It’s an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can’t do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10.能力越大责任越大(With great power comes great responsibility)

毫无疑问,软件已成为我们生活中一个既基本又重要的一部分。正因如此,开发优秀软件格外重要。乒乓球游戏中的Bug是一回事,航天飞机导向系统或者航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文,讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今天写的代码,无论你是否有意,说不定有朝一日在重要的应用程序中派上用场,这想想都令人害怕。编写正确合格的代码吧!

原文:

Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It’s one thing to have a bug in a game of Pong, it’s another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It’s a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.

Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!

转载于公众号:程序猿DD


SQL优化怎么做?来这里看看!

科技创新木土走召 发表了文章 • 0 个评论 • 137 次浏览 • 2021-05-25 15:58 • 来自相关话题

前言在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。SQL优化一般步骤1、通过慢查日志等定位那些执行效率较低的SQ... ...查看全部

前言

在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。

SQL优化一般步骤

1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划

需要重点关注type、rows、filtered、extra。

type由上至下,效率越来越高

  • ALL 全表扫描

  • index 索引全扫描

  • range 索引范围扫描,常用语<,<=,>=,between,in等操作

  • ref 使用非唯一索引扫描或唯一索引前缀扫描,返回单条记录,常出现在关联查询中

  • eq_ref 类似ref,区别在于使用的是唯一索引,使用主键的关联查询

  • const/system 单条记录,系统会把匹配行中的其他列作为常数处理,如主键或唯一索引查询

  • null MySQL不访问任何表或索引,直接返回结果 虽然上至下,效率越来越高,但是根据cost模型,假设有两个索引idx1(a, b, c),idx2(a, c),SQL为”select * from t where a = 1 and b in (1, 2) order by c”;如果走idx1,那么是type为range,如果走idx2,那么type是ref;当需要扫描的行数,使用idx2大约是idx1的5倍以上时,会用idx1,否则会用idx2

Extra

  • Using filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序,并按排序顺序检索行。

  • Using temporary:使用了临时表保存中间结果,性能特别差,需要重点优化

  • Using index:表示相应的 select 操作中使用了覆盖索引(Coveing Index),避免访问了表的数据行,效率不错!如果同时出现 using where,意味着无法直接通过索引查找来查询到符合条件的数据。

  • Using index condition:MySQL5.6之后新增的ICP,using index condtion就是使用了ICP(索引下推),在存储引擎层进行数据过滤,而不是在服务层过滤,利用索引现有的数据减少回表的数据。

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的,开启语句“set profiling = 1;”

SHOW PROFILES ;SHOW PROFILE FOR QUERY  #{id};
4、trace

trace分析优化器如何选择执行计划,通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

set optimizer_trace="enabled=on";set optimizer_trace_max_mem_size=1000000;select * from information_schema.optimizer_trace;
5、确定问题并采用相应的措施
  • 优化索引

  • 优化SQL语句:修改SQL、IN 查询分段、时间查询分段、基于上一次数据过滤

  • 改用其他实现方式:ES、数仓等

  • 数据碎片处理

场景分析

案例1、最左匹配

索引

KEY `idx_shopid_orderno` (`shop_id`,`order_no`)

SQL语句

select * from _t where orderno=''

查询匹配从左往右匹配,要使用order_no走索引,必须查询条件携带shop_id或者索引(shop_id,order_no)调换前后顺序

案例2、隐式转换

索引

KEY `idx_mobile` (`mobile`)

SQL语句

select * from _user where mobile=12345678901

隐式转换相当于在索引上做运算,会让索引失效。mobile是字符类型,使用了数字,应该使用字符串匹配,否则MySQL会用到隐式替换,导致索引失效。

案例3、大分页

索引

KEY `idx_a_b_c` (`a`, `b`, `c`)

SQL语句

select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;

对于大分页的场景,可以优先让产品优化需求,如果没有优化的,有如下两种优化方式, 一种是把上一次的最后一条数据,也即上面的c传过来,然后做“c < xxx”处理,但是这种一般需要改接口协议,并不一定可行。另一种是采用延迟关联的方式进行处理,减少SQL回表,但是要记得索引需要完全覆盖才有效果,SQL改动如下

select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;
案例4、in + order by

索引

KEY `idx_shopid_status_created` (`shop_id`, `order_status`, `created_at`)

SQL语句

select * from _order where shop_id = 1 and order_status in (1, 2, 3) order by created_at desc limit 10

in查询在MySQL底层是通过 n*m 的方式去搜索,类似union,但是效率比union高。in查询在进行cost代价计算时(代价 = 元组数 * IO平均值),是通过将in包含的数值,一条条去查询获取元组数的,因此这个计算过程会比较的慢,所以MySQL设置了个临界值(eq_range_index_dive_limit),5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200,即in条件超过了200个数据,会导致in的代价计算存在问题,可能会导致Mysql选择的索引不准确。

处理方式,可以(order_statuscreated_at)互换前后顺序,并且调整SQL为延迟关联。

案例5、范围查询阻断,后续字段不能走索引

索引

KEY `idx_shopid_created_status` (`shop_id`, `created_at`, `order_status`)

SQL语句

select * from _order where shop_id = 1 and created_at > '2021-01-01 00:00:00' and order_status = 10

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。(可以用到ICP)
select * from _order where shop_id=1 and order_status not in (1,2)select * from _order where shop_id=1 and order_status != 1

在索引上,避免使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小,则优化器还是会选择辅助索引,但是当访问的数据占整个表中数据的蛮大一部分时(一般是20%左右),优化器会选择通过聚集索引来查找数据。

select * from _order where  order_status = 1

查询出所有未支付的订单,一般这种订单是很少的,即使建了索引,也没法使用索引。

案例8、复杂查询
select sum(amt) from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01';select * from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01' limit 10;

如果是统计某些数据,可能改用数仓进行解决;如果是业务上就有那么复杂的查询,可能就不建议继续走SQL了,而是采用其他的方式进行解决,比如使用ES等进行解决。

案例9、asc和desc混用
select * from _t where a=1 order by b desc, c asc

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储,可能数据量会很大,如果在方案的选择上,最终选择存储在MySQL上,并且做7天等有效期的保存。那么需要注意,频繁的清理数据,会照成数据碎片,需要联系DBA进行数据碎片处理。

转载于公众号“程序猿”DD


【文末附PPT】融云2021 X-Meetup续航上海 以场景应用解析音视频技术新方向

技术活动admin 发表了文章 • 0 个评论 • 149 次浏览 • 2021-05-19 14:04 • 来自相关话题

2021年5月15日,融云X-Meetup技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”,由融云音视频研发高级工程师姜春雨、时光机器人创始人兼CEO徐晶、融云IM研发中心高级工程师刘佳、学而思网校架构师李亚龙,和资深音视频技术专家栗伟,五位技术大咖出... ...查看全部

2021年5月15日,融云X-Meetup技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”,由融云音视频研发高级工程师姜春雨、时光机器人创始人兼CEO徐晶、融云IM研发中心高级工程师刘佳、学而思网校架构师李亚龙,和资深音视频技术专家栗伟,五位技术大咖出任演讲嘉宾,他们以时下热门应用场景为视角,从技术实践出发,与开发者们交流分享了关于音视频技术新观察。微信图片_20210519115507.jpg

iOS 上的音频开发

今年,由于Clubhouse和Tiya的示范效应,语聊房产品大火,音频的开发技术备受开发者的关注。来自融云的音视频研发高级工程师姜春雨,多年专注于移动端和音视频领域的技术研发,他分享了《iOS 音频设备开发 - Core Audio》的主题内容。

微信图片_20210519115501.png

融云音视频研发高级工程师姜春雨发表演讲

姜春雨认为:移动端音频处理的难点在于声音美化、变声、实时高音质和场景玩法多样化。单从iOS设备来说,要突破这些难点,离不开iOS所提供的Audio Unit,它是一项强大灵活的音频处理技术,支持混合、均衡、格式转换和实时输入/输出,用于录制、播放、离线渲染和实时对话。

融云SDK以Audio Unit为基础,构建了长音效、短音效等多个功能模块,最终在音频设备上完成混音输出。在场景化实践中,姜春雨以音乐语聊房和百人超大会议室两个典型场景为例,分享了融云SDK的技术开发优化方案。比如,音乐语聊房注重高音质、美声变声,以舒适噪音为好,开发者要根据这些需求进行算法调优;而超大会议室的优化则要求做到服务端智能发流、多人声音同时出现可以智能选择会议发言人的声音。

姜春雨总结道:Audio Unit是一个强大的音频处理框架,音频处理要基于Audio Unit框架构建内容,并且要在音频处理内容上不断打磨优化。未来,融云音视频SDK还将不断基于不同场景需要开发新的功能,持续优化音频产品,为开发者提供更好的解决方案。

构建低延迟高可靠的信令系统

融云作为互联网通信云赛道的领先厂商,2020年在业界率先提出“IM+RTC+PUSH”的整体通信解决方案。融云RTC唤起用户的通道就是依赖于IM的SDK信令,因此,本次融云的IM研发中心高级工程师刘佳,分享了《构建低延迟高可靠信令系统的探索与实践》,帮助开发者更好地了解融云IM如何协同RTC,提供高可靠的通信能力。

微信图片_20210519115504.png

 融云IM研发中心高级工程师刘佳

刘佳介绍,高可靠音视频信令系统的构建在IM信令系统设计时,首先要进行服务分层,包括接入层、内部服务和数据存储的分层。而拆分原则要根据业务差异和服务对象的不同,拆分为API和 CMP,整体做到可监控、可维护。其次,是要搭建完整的监控体系,通过可视化的图表,监看网络的性能情况,及时处理系统瓶颈。

对于低延迟信令系统的实现,刘佳分享道,融云不仅利用全球加速网络,降低网络延迟,还基于融云自有通讯协议降低数据传输量,利用缓存机制,提高了服务的业务处理速度。并且,刘佳以缓存设计为例,说明通过一致性hash提高缓存命中率、高效利用CPU的处理能力、实施异步存储等,也都是实现低延迟系统设计的要旨。

基于这些设计要点,刘佳展示了海量并发用户场景下的语聊房系统架构,为开发者提供了干货解决方案。同时,他还总结出融云现有的音视频整体服务架构的三大优势:第一,信令服务与媒体服务解藕,两个服务之间也不需要状态同步;第二,媒体服务专注通信,信令服务专注能力;第三,部署简单,方便进行全球部署媒体服务。

直播系统架构设计 满足用户对实时性的需求

本场沙龙中,音视频直播场景也是一个重点话题。深耕互联网音视频12年,在直播领域积累了丰富实战经验的拾光机器人公司创始人兼 CEO徐晶,通过他的《互联网直播快速实战》,分享了基于直播答题场景的架构设计,尤其是几个关键技术点和应对策略,以及如何保证直播中的视频和音频质量,了详细的讲解。

沙龙中,专注于在线教育的学而思网校架构师李亚龙,还针对教育低延时大班的直播场景,为开发者带来了关于《在线教育直播系统架构升级》的分享。他着重从网校视频技术的发展、网校大班直播系统、网校公益直播课、低延迟直播探索这四个方面的设计要点,进行了分析讲解。对于专注在线教育的开发者而言,具有普遍的示范意义。

此外,资深音视频技术专家的栗伟,发表了《使用webrtc构建实时在线课堂》的演讲。栗伟曾任职于中科院计算所、CC视频,任职期间利用WebRTC技术开发了直播、在线课堂、视频会议等商业产品,并发用户数达到500万。他还曾主笔撰写了 《WebRTC技术详解:从0到1构建多人视频会议系统》,在该领域有多年实践经验,对WebRTC有非常深入的研究,他的实践分享让开发者们获益匪浅。

结语

在本次沙龙中,五位讲师的分享,其共性特点在于:他们都基于当下所关注热门场景展开话题。由此可见,应用场景才是“探讨音视频技术新方向”的基础,而越热门的场景往往越是代表着这个领域的发展潜力更大,因此也就越需要通过新技术、新产品加以承载。

随着5G的进一步落地,网络带宽、网络质量的不断优化,音视频通信无论在使用量级上,还是使用场景上,都会出现更多可能。对于开发者而言,只有及早储备,尽可能多地掌握新技术,关注新方向,才能赢在当下,赢在未来。

讲师PPT下载↓

0515演讲PPT.pdf

刷爆全网:一个中科大差生的8年程序员工作总结(上)

科技创新王叫兽 发表了文章 • 0 个评论 • 91 次浏览 • 2021-05-14 15:35 • 来自相关话题

今年终于从大菊花厂离职了,离职前收入大概 60w 不到吧!在某乎属于比较差的,今天终于有空写一下自己的职场故事,也算是给自己近 8 年的程序员工作做个总结复盘。近 8 年有些事情做对了,也有更多事情做错了,在这里记录一下,希望能够给后人一些帮助吧,也欢迎私信交... ...查看全部

今年终于从大菊花厂离职了,离职前收入大概 60w 不到吧!在某乎属于比较差的,今天终于有空写一下自己的职场故事,也算是给自己近 8 年的程序员工作做个总结复盘。

近 8 年有些事情做对了,也有更多事情做错了,在这里记录一下,希望能够给后人一些帮助吧,也欢迎私信交流。文笔不好,见谅,有些细节记不清了,如果有出入,就当是我编的这个故事吧。

PS:有几个问题先在这里解释一下,评论就不一一回复了

1.关于差生,我本人在科大时确实成绩偏下,差生主要讲这一点,没其他意思。

2.因为买房是我人生中的大事,我认为需要记录和总结一下,本文中会有买房,房价之类的信息出现,您如果对房价,炒房等反感的话,请您停止阅读,并且我再这里为浪费您的时间先道个歉。

2013 年
加入上海航天 x 院某卫星研究所

本人 86 年生人,13 年从中科大软件相关专业毕业,由于父母均是老师,从小接受的教育就是努力学习,找个稳定的“好工作”,报效国家。

于是乎,毕业时候头脑一热加入了上海航天 x 院某卫星研究所,没有经过自己认真思考,仅仅听从父母意见,就草率的决定了自己的第一份工作,这也为我 5 年后离职埋下了隐患。这里总结第一条经验:

如果你的亲人是普通阶层,那对于人生中一些大事来说,他们给的建议往往就是普通阶层的思维,他们的阶层就是他们一生思维决策的结果,如果你的目标是跳出本阶层,那最好只把他们的建议当成参考。

13 年 4 月份,我坐上火车来到上海,在一路换乘地铁来到了大闵行,出了地铁走路到单位,一路上建筑都比较老旧,我心里想这跟老家也没什么区别嘛,还大上海呢。

到达单位报道,负责报道的老师很亲切,填写完资料,分配了一间宿舍,还给了大概 3k 左右安家费,当时我心里那个激动啊(乡下孩子没有见过钱啊,见谅),拿了安家费,在附近小超市买好生活用品,这样我就开始了自己航天生涯。

经过 1 个月集中培训后,我分配到部门,主要负责卫星上嵌入式软件开发。不过说是高大上的卫星软件开发,其实刚开始就是打杂,给实验室、厂房推箱子搬设备,呵呵,说航天是个体力活相信很多航天人都有同感吧。不过当时年轻,心思很单纯,每天搬完设备,晚上主动加班,看文档材料,画软件流程图,编程练习,日子过得很充实。

记得第一个月到手大概 5k 左右(好少呀),当时很多一起入职的同事抱怨,我没有,我甚至不太愿意和他们比较工资,这里总结第二条经验:

不要和你的同事比工资,没有意义,比工资总会有人受伤,更多的是负面影响,并且很多时候受伤的会是你。

工作中暂露头角

工作大概一个月的时候,我遇到了一件事情,让我从新员工里面开始暂露头角。事情是这样的当时国家要对军工单位进行 GJB5000A 软件开发等级认证(搞过这个认证的同学应该都知道,过这个认证那是要多酸爽有多酸爽),但是当时一个负责配置管理的同事却提出离职,原因是他考上了公务员,当时我们用的那个软件平台后台的版本控制是 SVN 实现的,恰好我在学校写程序时用过,呵呵,话说回来现在学生自己写软件很少有人会在本地搭版本控制器吧!我记得当时还被同学嘲笑过,这让我想起了乔布斯学习美术字的故事,这里总结一下:

不要说一项技能没有用,任何你掌握的技能都有价值,但是你要学会找到发挥它的场景。如果有一天你落水了,你可能会很庆幸,自己以前学会了游泳。

工作中如果要上升,你要勇于承担麻烦的、有挑战的任务,当你推掉麻烦的时候,你也推掉了机遇。

好了,扯远了,回到前面,当时我主动跟单位认证负责人提出,我可以帮忙负责这方面的工作,我有一定经验。这里要提一下这个负责人,是位女士,她是我非常敬佩的一个前辈,认真,负责,无私,整个人为国家的航天事业奉献了几十年,其实航天领域有非常多这样的老前辈,他们默默奋斗,拿着不高的薪水,为祖国的国防建设做出了巨大的贡献。当时这位负责人,看我平时工作认真积极,思维反应也比较灵活(因为过认证需要和认证专家现场答辩的)就同意了我的请求,接受到这个任务之后,我迅速投入,学习认证流程、体系文件、迅速掌握认证工作要点,一点一点把相关的工作做好,同时周期性对业务进行复盘,总结复盘可能是我自己的一个优点:

很多人喜欢不停的做事,但不会停下来思考,缺乏总结复盘的能力,其实阶段性总结复盘,不仅能够固化前面的经验,也能梳理后面的方向;把事情做对很重要,但是更重要的是做对的事;另外不要贪快,方向正确慢就是快(后半句是我后来才想明白的,如果早想明白,就不会混成目前这样了)

1 个月后,当时有惊无险通过了当年的认证,当时负责人主动向单位申请了 2k 特别奖,当时我真的非常高兴,主要是自己的工作产生了价值,得到了认可。后来几个月的日子平淡无奇,有印象的好像只有两件事情。

一件事情是当年端午,当时我们在单位的宿舍休息,突然楼道上一阵骚动,我打开宿舍门一看,原来是书记来慰问,还给每个人送了一箱消暑饮料,这件事印象比较深刻,是我觉得国企虽然有各种各样的问题,但是论人文关怀,还是国企要好得多。

错失一次暴富的机会

另一件事是当年室友刚买房,然后天天研究生财&之道,一会劝我买房,一会劝我买比&特&币,我当时没有鸟他,为什么呢,因为当时的室友生活习惯不太好,会躺在床上抽烟,还在宿舍内做饭(我们宿舍是那种很老的单位房,通风不好),我有鼻炎,所以不是很喜欢他(嗯,这里要向室友道歉,当年真是太幼稚了)。现在 B&T&C4 万美元了,我当时要是听了室友也能小发一笔了(其实我后来 18 年买了,但是没有拿住这是后话),这里要总结一下:

不要因为某人的外在,如外貌、习惯、学历等对人贴上标签,去盲目否定别人,对于别人的建议,应该从客观出发,综合分析,从善如流是一项非常难得的品质。

人很难挣到他认知之外的财富,就算偶然拿到了,也可能很快失去。所以不要羡慕别人投机获得的财富,努力提升你的思维,财商才是正道。

航天生涯的第一个正式项目

转眼到了 9 月份(我 4 月份入职的),我迎来了我航天生涯第一个正式的型号项目(型号,是军工的术语,就相当于某个产品系列比如华为的 mate),当时分配给我的型号正式启动,我终于可以开始写卫星上的代码了。

当时真的是心无旁骛,一心投身军工码农事业,每天实验室,测试厂房,评审会,日子虽然忙碌,但是也算充实。并且由于我的努力工作,加上还算可以的技术水平,我很快就能独立胜任一些型号基础性的工作了,并且我的努力也受到了型号(产品)线的领导的认可,他们开始计划让我担任型号主管设计师,这是一般工作 1-2 年的员工的岗位,当时还是有的激动的。

2014 年
升任主管设计师后的一次波折

转眼间到 2014 年了,大概上半年吧,我正式升任主管设计师,研发工作上也开时独挡一面了,但是没多久产品研发就给了我当头一棒。

事情是这样的,当时有一个版本软件编写完毕,加载到整星上进行测试,有一天大领导来检查,当时非常巧,领导来时测试主岗按某个岗位的人员要求,发送了一串平时整星没有使用的命令(我在实验室是验证过的),结果我的软件立刻崩溃,无法运行。由于正好领导视察,这个问题立马被上报到质量处,于是我开始了苦逼的技术归零攻关(搞航天的都懂,我就不解释了)。

期间每天都有 3 个以上领导,询问进度,当时作为新人的我压力可想而知,可是我无论如何都查不出来问题,在实验室我的软件完全正常!后来,某天中午我突然想到,整星上可能有不同的环境,具体过程就不说了。后人查出来是一个负责加载我软件的第三方软件没有受控,非法篡改了我程序的 4 个字节,而这 4 字节正好是那天发送命令才会执行的代码,结果导致我的软件崩溃。最后我花了进一个月完成了所有质量归零报告,技术分析报告,当然负责技术的领导没有责怪,相反的还更加看重我了,后来我每遇到一个质量问题,无论多忙最后定要写一份总结分析报告,这成了我一个技术习惯,也为后来我升任软件开发组长奠定了技术影响基础。

强烈建议技术团队定期开展质量回溯,需要文档化,还要当面讲解,深入的技术回溯有助于增加团队技术交流活跃度,同时提升团队技术积淀,是提升产品质量,打造优秀团队的有效方法。

个人的话建议养成写技术总结文章的习惯,这不仅能提升个人技术,同时分享也可以增加你的影响力

职场软技能的重新认识

上半年就在忙碌中度过了,到了年底,发生了一件对我们组影响很大的事情,年底单位开展优秀小组评比, 其实这个很多公司都有,那为什么说对我们组影响很大内,这里我先卖关子。这里先不得不提一个人,是个女孩子,南京大学的,比我晚来一年,她做事积极,反应灵敏,还做得一手不错的 PPT,非常优秀,就是黑了点(希望她看到了不要来找我,呵呵)。

当时单位开展优秀小组评比,我们当时是新员工,什么都很新鲜,就想参加一下,当时领导说我们每年都参加的,我们问,我们每年做不少东西,怎么没有看到过评比的奖状,领导有点不好意思,说我们没有进过决赛。我们又问,多少名可以进入决赛圈,答曰前 27 名即可(总共好像 50+个组)我们当时心里真是一万个羊驼跑过。。。。

其实当时我们组每年是做不少事情的,我们觉得我们不应该排名如此之低,于是我们几个年轻人开始策划,先是对我们的办公室彻底改造(因为要现场先打分,然后进决赛),然后好好梳理了我们当年取得的成绩,现场评比时我自告奋勇进行答辩(我沟通表达能力还不错,这也算我一个优势吧),后面在加上前文提到的女孩子做的漂亮 PPT,最后我们组拿到了铜牌班组的好成绩,我也因为这次答辩的优秀表现在领导那里又得到了认可,写了大半段了,再总结一下:

职场软技能如自我展示很重要,特别是程序员,往往在这方面是个弱项,如果可以的话,可以通过练习,培训强化一下这些软技能,对职场的中后期非常有帮助。

2015 年

时间总是过得很快,一下就到 2015 年了,这一年发生了一件对我影响很大的事情。

升任小组副组长

当时我们小组有 18 个人了,有一天部门开会,主任要求大家匿名投票选副组长(当时部门领导还是很民主的),因为日常事务逐渐增多,老组长精力有限,想把一些事物分担出来,当天选举结果就出来了,我由于前面的技术积累和沟通表达能力的展现,居然升任副组长,当时即有些意外,因为总是有传言说国企没背景一辈子就是最最底层,后来我仔细思考过,下面是我不成熟的想法:

不要总觉得国企事业单位的人都是拼背景,拼关系,我承认存在关系户,但是不要把关系户和低能力挂钩,背景只是一个放大器,当关系户做出了成绩时它会正面放大影响,当关系户做了不光彩的事情是,它也会让影响更坏。没有背景,你可以作出更大的贡献来达到自己的目标,你奋斗的过程是更大的财富。另外,我遇到的关系户能力都很强,也可能是巧合,也可能是他们的父辈给给他们在经验层次上比我们更优秀的教育。

学习团队管理技巧

升任副组长后,我的工作更加忙碌了,不仅要做自己项目的事情,还要横向管理和协调组内其他项目的事情,有人说要多体谅军工单位的基层班组长,这话真是没错啊。这个时候我开始学习一些管理技巧,如何凝聚团队,如何统一协调资源等等,这段时间我还是在不断成长。不过记得当年还是犯了一个很大的方向性错误,虽然更多的原因可能归结为体制吧,但是当时其实可以在力所能及的范围内做一些事情的。

具体是这样的,当时管理上有项目线,有行政线,就是很常见的矩阵式管理体系,不过在这个特殊的体制下面出现了一些问题。当时部门一把手被上级强制要求不得挂名某个型号,因为他要负责部门资源调配,而下面的我们每个人都归属 1-2 个型号(项目),在更高层的管理上又有横向的行政线(不归属型号),又有纵向的型号管理线。

而型号的任务往往是第一线的,因为产品还是第一位的,但是个人的绩效、升迁又归属行政线管理,这种形式在能够高效沟通的民企或者外企一般来说不是问题,但是在沟通效率缓慢,还有其他掣肘因素的国企最终导致组内每个人忙于自身的型号任务,各自单打独斗,无法聚焦,一年忙到头最终却得不到部门认可,我也因为要两面管理疲于应付,后来曾经反思过,其实可以聚焦精力打造通用平台(虽然这在我们行业很难)部分解决这个问题:

无论个人还是团队,做事情要聚焦,因为个人和团队资源永远都是有限的,如果集中一个事情都做不好,那分散就更难以成功,但是在聚焦之前要深入思考,往什么方向聚焦才是正确的,只有持续做正确的事情才是最重要的。

2016 年

这一年是我人生的关键一年,发生了很多事情。

升任小组组长

第一件事情是我正式升任组长,由于副组长的工作经验,在组长的岗位上也做得比较顺利,在保证研发工作的同时,继续带领团队连续获得铜牌以上班组奖励,另外各种认证检查都稳稳当通过,但是就在这个时候,因为年轻,我犯下了一个至今非常后悔的错误。

大概是这样的,我们部门当时有两个大组,一个是我们的软件研发组,一个是负责系统设计的系统分析组。

当时两个组的工作界面是系统组下发软件任务书给软件组,软件组依照任务书开发,当时由于历史原因,软件组有不少 10 年以上的老员工,而系统组由于新成立由很多员工工作时间不到 2 年,不知道从什么时候起,也不知道是从哪位人员开始,软件组的不少同事认为自己是给系统组打工的。并且,由于系统组同事工作年限较短,实际设计经验不足,任务书中难免出现遗漏,从而导致实际产品出错,两组同事矛盾不断加深。

最后,出现了一个爆发:当时系统组主推一项新的平台,虽然这个平台得到了行政线的支持,但是由于军工产品迭代严谨,这个新平台当时没有型号愿意使用,同时平台的部分负责人,居然没有完整的型号经验!由于这个新平台的软件需要软件组实现,但是因为已经形成的偏见,软件同事认为这项工作中自己是为利益既得者打工。

我当时也因为即负责实际软件开发,又负责部分行政事务,并且年轻思想不成熟,也持有类似的思想。过程中的摩擦、冲突就不说了,最后的结果是系统组、软件组多人辞职,系统组组长离职,部门主任离职创业(当然他们辞职不全是这个原因,包括我离职也不全是这个原因,但是我相信这件事情有一定的影响),这件事情我非常后悔,后来反思过其实当时自己应该站出来,协调两组矛盾,全力支持部门技术升级,可能最终就不会有那么多优秀的同事离开了。

公司战略的转型,技术的升级迭代,一定会伴随着阵痛,作为基层组织者,应该摒弃个人偏见,带领团队配合部门、公司主战略,主战略的成功才是团队成功的前提。

买房

16 年我第二件大事情就是买房,关注过近几年房价的人都可能还记得,16 年一线城市猛涨的情景。其实当时 15 年底,上海市中心和学区房已经开始上涨,我 15 年底听同事开始讨论上涨的房价,我心里开始有了买房的打算,大约 16 春节(2 月份吧,具体记不得了),我回老家探望父母,同时跟他们提出了买房的打算。

我的父亲是一个“央视新闻爱好者”,爱好看狼咸平,XX 刀,XX 檀的节目,大家懂了吧,父亲说上海房价太高了,都是泡沫,不要买。这个时候我已经不是菜鸟了,我想起我总结的第一条经验(见上文),我开始收集往年的房价数据,中央历年的房价政策,在复盘 15 年的经济政策时我发现,当年有 5 次降息降准,提升公积金贷款额度,放松贷款要求于是我判定房价一定会继续涨,涨到一个幅度各地才会出台各种限购政策,并且房价在城市中是按内环往外涨的于是我开始第一次在人生大事上反对父母,我坚决表态要买房。父亲还是不太同意,他说年底吧,先看看情况(实际是年底母亲的退休公积金可以拿出来大概十几万吧,另外未来丈母娘的公积金也能拿出来了大概比这多些)。我还是不同意,父亲最终拗不过我,终于松口,于是我们拿着双方家庭凑的 50w 现金开始买房,后来上海的房价大家都看到了。这件事也是我做的不多的正确的事情之一。

但是最可笑的是,我研究房价的同时居然犯下了一个匪夷所思的错误,我居然没有研究买房子最重要的因素是什么,我们当时一心想买一手房(现在想想真是脑子进水),最后买了一套松江区交通不便的房子,这第一套房子的地理位置也为我后来第二次离职埋下了隐患,这个后面会说。

一线或者准一线城市能买尽量买,不要听信房产崩溃论,如果买不起,那可以在有潜力的城市群里用父母的名义先买一套,毕竟大多数人的财富其实是涨不过通货膨胀的。另外买房最重要的三个要素是,地段,地段,地段。

买房的那天上午和女朋友领的证,话说当时居然把身份证写错了三次 。。。

这下我终于算是有个家了,交完首付那个时候身上真的是身无分文了。航天的基层员工的收入真的是不高,我记得我当时作为组长,每月到手大概也就 7k-8k 的样子,另外有少量的奖金,但是总数仍然不高,好在公积金比较多,我日常也没什么消费欲望,房贷到是压力不大。

买完房子之后,我心里想,这下真的是把双方家庭都掏空了(我们双方家庭都比较普通,我的收入也在知乎垫底,没办法)万一有个意外怎么办,我思来想去,于是在我下一个月发工资之后,做了一个我至今也不知道是对是错的举动,我利用当月的工资,给全家人家人买了保险保险,各种重疾,意外都配好了。但是为什么我至今也不知道对错呢,因为后来老丈人,我母亲都遭遇病魔,但是两次保险公司都拒赔,找出的理由我真是哑口无言,谁叫我近视呢。另外真的是要感谢国家,亲人重病之后,最终还是走了医保,赔偿了部分,不然真的是一笔不小的负担。

2017 年

对我人生重大影响的 2016 年,在历史的长河中终究连浪花都激不起来。历史长河静静流淌到了 2017 年,这一年我参加了中国深空探测项目,当然后面我没有等到天问一号发射就离开了航天,但是有时候仰望星空的时候,想想我的代码正在遥远的星空发挥作用,心里也挺感慨的,我也算是重大历史的参与者了,呵呵。好了不说工作了,平淡无奇的 2017 年,对我来说也发生了两件大事。

买了第二套房子

第一件事是我买了第二套房子,说来可笑,当年第一套房子都是掏空家里,这第二年就买了第二套房子,生活真的是难以捉摸。到 2017 年时,前文说道,我母亲和丈母娘先后退休,公积金提取出来了,然后在双方家里各自办了酒席,酒席之后,双方父母都把所有礼金给了我们,父母对自己的孩子真的是无私之至。当时我们除了月光之外,其实没有什么外债,就是生活简单点。拿到这笔钱后,我们就在想如何使用,一天我在菜市场买菜,有人给我一张 xuanchuan 页,本来对于这样的 xuanchuan 页我一般是直接扔掉的,但是当天鬼死神差我看了一眼,只见上面写着“嘉善高铁房,紧邻上海 1.5w”我当时就石化了,我记得去年我研究上海房价的时候,曾经在网站上看到过嘉善的房价,我清楚的记得是 5-6k,我突然意识到我是不是错过了什么机会,反思一下:

工作生活中尽量保持好奇心,不要对什么的持怀疑态度,很多机会就隐藏在不起眼的细节中,比如二十年前有人告诉你未来可以在网上购物,有人告诉你未来可以用手机支付,你先别把他直接归为骗子,静下来想一想,凡事要有好奇心,但是要有自己的判断。

于是我立马飞奔回家,开始分析,大城市周边的房价。我分析了昆山,燕郊,东莞,我发现燕郊极其特殊,几乎没有产业,纯粹是承接大城市人口溢出,因此房价成高度波动。而昆山和东莞,由于自身有产业支撑,又紧邻大城市,因此房价稳定上涨。我和妻子一商量,开始了外地看房之旅,后来我们去了嘉善,觉得没有产业支撑,昆山限购,我们又到嘉兴看房,我发现嘉兴房价也涨了很多,但是这里购房的大多数新房,都是上海购房者,入住率比较低,很多都是打算买给父母住的,但是实际情况是父母几乎不在里面住,我觉得这里买房不妥,存在一个变现的问题。于是我开始继续寻找,一天我看着杭州湾的地图,突然想到,杭州湾北侧不行,那南侧呢?南侧绍兴,宁波经济不是更达吗。于是我们目光投向绍兴,看了一个月后,最后在绍兴紧贴杭州的一个区,购买了一套小房子,后来 17 年房价果然如我预料的那样完成中心城市的上涨之后开始带动三四线城市上涨。后来国家出台了大湾区政策,我对我的小房子更有信心了。这里稍微总结一下我个人不成熟的看法:

在稳定通胀的时代,负债其实是一种财富。长三角城市群会未来强于珠港澳,因为香港和澳门和深圳存在竞争关系,而长三角城市间更多的是互补,未来我们看澳门可能就跟看一个中等省会城市一样了。

准备要孩子

2017 年的第二件事是,我们终于准备要孩子了,但是妻子怎么也备孕不成功,我们开始频繁的去医院,从 10 元挂号费的普通门诊,看到 200 元,300 元挂号费的专家门诊,看到 600 元的特需门诊,从综合医院看到妇幼医院,从西医看到中医,每个周末不是在医院排队,就是在去医院的路上。最后的诊疗结果是有一定的希望,但是有困难,得到消息时我真的感觉眼前一片黑暗,这种从来在新闻上才能看到了事情居然落到了我们头上,我们甚至开始接触地下 XX 市场。同时越来越高的医疗开销(专家门诊以上就不能报销了)也开始成为了我的负担,前文说了,我收入一直不高,又还贷款,又支付医疗开支渐渐的开始捉襟见肘,我甚至动了卖小房子的打算。

未完待遇~

刷爆全网:一个中科大差生的8年程序员工作总结(下)

科技创新王叫兽 发表了文章 • 0 个评论 • 119 次浏览 • 2021-05-14 15:35 • 来自相关话题

2018 年前面说到,2017 年开始频繁出入医院,同时项目也越来越忙,我渐渐的开始喘不过气起来,最后医生也给了结论,需要做手术,手术有不小的失败的几率。我和妻子商量后一咬牙做吧,如果失败就走地下的路子,但是可能需要准备一笔钱(手术如果成功倒是花销不会太大),... ...查看全部
2018 年

前面说到,2017 年开始频繁出入医院,同时项目也越来越忙,我渐渐的开始喘不过气起来,最后医生也给了结论,需要做手术,手术有不小的失败的几率。我和妻子商量后一咬牙做吧,如果失败就走地下的路子,但是可能需要准备一笔钱(手术如果成功倒是花销不会太大),哎,古人说一分钱难倒英雄汉,真是诚不欺我啊,这个时候我已经开始萌生离职的想法了。怎么办呢,生活还是要继续,我想起了经常来单位办理贷款的银行人员,贷款吧,这种事情保险公司肯定不赔的嘛,于是我办理了一笔贷款,准备应急。

项目结束,离职

时间慢慢的时间走到了 8 月份,我的项目已经告一定段落,一颗卫星圆满发射成功,深空项目也通过了初样阶段我的第一份工作也算有始有终了。我开始在网上投递简历,我技术还算可以,沟通交流也不错,面试很顺利,一个月就拿到了 6 个 offer,其中就有大菊花厂的 offer,定级 16A,25k 月薪后来政策改革加了绩效工资 6k(其实我定级和总薪水还是有些偏低了和我是国企,本来总薪水就低有很大关系,话说菊花厂级别后面真的是注水严重,博士入职轻松 17 级)菊花厂的 offer 审批流程是我见过最长,我当时的接口人天天催于流程都走了近 2 个月。

我向领导提出了离职,离职的过程很痛苦,有过经历的人估计都知道,这里就不说了。话说我为什么会选择华为呢,一是当时急需钱,二是总觉得搞嵌入式的不到华为看看真的是人生遗憾。现在想想没有认真去理解公司的企业文化就进入一家公司还是太草率了:

如果你不认同一个公司的企业文化,你大概率干不长,干不到中高层,IT 人你不及时突破到中高层很快你就会面临非常多问题;公司招人主要有两种人,一种是合格的人,一种是合适的人,合格的人是指技能合格,合适的人是指认同文化。企业招人就是先把合格的人找进来,然后通过日日宣讲,潜移默化把不合适的人淘汰掉。

入职华为

经过一阵折腾终于离职成功,开始入职华为。离职我做了一件比较疯狂的事情,当时因为手上有一笔现金了,一直在支付利息,心里就像拿它干点啥。那时由于看病,接触了地下 XX 市场,听说了 B&TC,走之前我心一横买 B&T&C,后来不断波动,最终我还是卖了,挣了一些钱,但是最终没有拿到现在,果然是考验人性啊。

2019 年
成功转正

华为的试用期真长,整整 6 个月,每个月还有流程跟踪,交流访谈,终于我转正了,转正答辩我不出意料拿到了 Excellent 评价,涨了点薪水,呵呵还不错。华为的事情我不太想说太多,总之我觉得自己没有资格评判这个公司,从公司看公司的角度华为真正是个伟大的公司,任老爷子也是一个值得敬佩的企业家。

在华为干了半年后,我发现我终究还是入职的时候太草率了,我当时没有具体的了解这个岗位,这个部门。入职之后我发现,我所在的是硬件部门,我在一个硬件部门的软件组,我真是脑子秀逗了。

在一个部门,你需要尽力进入到部门主航道里,尽力不要在边缘的航道工作,特别是那些节奏快,考核严格的部门。

更严峻的是我所在的大组,居然是一个分布在全国 4 地的组,大组长(华为叫 LM)在上海,4 地各有一个本地业务负责人。我立刻意识到,到年终考评时,所有的成果一定会是 4 地分配,并且 4 地的负责人会占去一大部分,这是组织结构形成的优势。我所在的小组到时候会难以突破,资源分配会非常激烈。

备孕成功

先不说这些,在 18 年时妻子做完了手术,手术居然很成功。休息完之后我们 19 年初开始备孕了,这次真的是上天保佑,运气不错,很快就怀上了。这段时间,我虽然每天做地铁 1.5 小时到公司上班,经受高强度的工作,我心里每天还是乐滋滋的。但是,突然有一天,PL(华为小组长)根我说,LM 需要派人去杭研所支持工作,我是最合适人选,让我有个心里准备。当时我是不想去的,这个时候妻子是最需要关怀的时候,我想 LM 表达了我的意愿,并且我也知道如果去了杭州年底绩效考评肯定不高。过程不多说了,反正结果是我去了杭州。

于是我开始了两头奔波的日子,每个月回上海一趟。这过程中还有个插曲,家里老家城中村改造,分了一点钱,父母执意卖掉了老家学校周边的房子,丈母娘也处理老家的一些房子,然后把钱都给了我们,然后我用这笔家里最后的资产,同时利用华为的现金流在绍、甬不限购地区购买一些房子,我没有炒房的想法,只是防止被通货膨胀侵蚀而已,不过后来结果证明我貌似又蒙对了啊,我自己的看法是:

杭绍甬在经济层面会连成紧密的一片,在行政区上杭州兼并绍 部分区域的概率其实不大,行政区的扩展应该是先兼并自身的下级代管城市。

宝宝出生

不说房子了,继续工作吧。10 月份干了快一年时候,我华为的师傅(华为有师徒培养体系)偷偷告诉我被定为备选 PL 了,虽然不知道真假,但是我心里还是有点小高兴。不过我心里也慢慢意识到这个公司可能不是我真正想要的公司,这么多年了,愚钝如我慢慢也开始知道自己想干什么了。因为我的宝宝出生了,看着这只四脚吞金兽,我意识到自己已经是一个父亲了。

2019 年随着美国不断升级的制裁消息,我在华为的日子也走到年底,马上将迎来神奇的 2020 年。

2020

2020 就少写一些了,有些东西真的可能忘却更好。

在家办公

年初就给大家来了一个重击,新冠疫情改变了太多的东西。这个时候真的是看出华为的执行力,居家办公也效率不减多少,并且迅速实现了复工。到了 3-4 月份,华为开始正式评议去年绩效等级,我心里开始有预感,以前的分析大概率会兑现,并且绩效和收入挂钩,华为是个风险意识极强的公司,去年的制裁会导致公司开始风险预备,虽然我日常工作还是受到多数人好评,但是我知道这其实在评议人员那里,没有任何意义。果然绩效评议结果出来了,呵呵,我很不满意。绩效沟通时 LM 破例跟我沟通了很长时间,我直接表达了我的想法。LM 承诺钱不会少,呵呵,我不评价吧。后来一天开始组织调整,成立一个新的小组,LM 给我电话让我当组长,我拒绝了,这件事情我不知道对错,我当时是这样考虑的

  1. 升任新的职位,未必是好事,更高的职位意味着更高的要求,因此对备选人员要么在原岗位已经能力有余,要么时间精力有余;我认为当时我这两个都不满足,呵呵离家有点远,LM 很可以只是因为绩效事情做些补偿。

  2. 华为不会垮,这点大家有信心,但未来一定会出现战略收缩,最后这艘大船上还剩下哪些人不清楚,底层士兵有可能是牺牲品。

  3. 我 34 岁了

提出离职

另外我一直思考未来想做什么,已经有了一丝眉目,就这样,我拿了年终奖约 7 月就提出了离职,后来部门还让我做了最后一次贡献,把我硬留到 10 月份,这样就可以参加上半年考核了,让帮忙背了一个 C 呵呵,这是工作多年,最差绩效吧。

这里还有一个小插曲,最后这三个月我负责什么工作呢,因为 20 年 3 月开始我就接手了部分部门招聘工作(在华为干过的都知道为什么非 HR 也要帮忙招聘,呵呵大坑啊,就不多解释了),结果最后三个月我这个待离职员工居然继续负责招聘,真的是很搞笑,不过由于我在上一份工作中其实一直也有招聘的工作,所以也算做的轻车熟路,每天看 50 份左右简历(我看得都非常仔细,我害怕自己的疏忽会导致一个优秀的人才错失机会,所以比较慢)其实也蛮有收货,最后好歹对程序员如何写简历有了一些心得。

总结

好了 7 年多,近 8 年的职场讲完了,不管过去如何,未来还是要继续努力,希望看到这篇文章觉得有帮助的朋友,可以帮忙点个推荐,这样可能更多的人看到,也许可以避免更多的人犯我犯的错误。

把中国 14 亿人都拉到一个群,技术上能实现吗?

科技创新王叫兽 发表了文章 • 0 个评论 • 86 次浏览 • 2021-05-14 15:24 • 来自相关话题

“最近,知乎上有一个非常热门的问题:“把 14 亿中国人民都拉到一个微信群里在技术上能实现吗?”实际上,根据国家统计局的数据,截至 2017 年末,中国大陆总人口为 13 亿 9008 万人(包括 31 个省、自治区、直辖市和中国人民解放军现役军人,不包括香港... ...查看全部

“最近,知乎上有一个非常热门的问题:“把 14 亿中国人民都拉到一个微信群里在技术上能实现吗?”

实际上,根据国家统计局的数据,截至 2017 年末,中国大陆总人口为 13 亿 9008 万人(包括 31 个省、自治区、直辖市和中国人民解放军现役军人,不包括香港、澳门和台湾以及海外华侨人数),早已超过 13 亿。

目前,微信群组成员人数上限为 500 人,把近 14 亿中国人都拉到一个微信群,从技术的角度考虑现实吗?需要多少台服务器?

而且在一个 14 亿人的群里,要怎样抢红包?手机会不会爆炸?欢迎大家收看官方吐槽系列~

根据 2017 年《微信数据报告》的公开数据 [参考 1] : 2017 年 9 月,微信日均登录 9.02 亿人,日均发送消息 380 亿次。

这意味着平均每人每天发送信息 42 条,如果全国人民(对了,现在全国人口已经接近 14 亿)在同一个群里说话,这个群每天出现的信息就高达:

这么多信息仅仅是匀速发送的话,考虑到大家的睡眠,睡觉的 8 小时不算,那么手机里每秒要接收的信息就是:

哇塞,每秒超过 100 万条啊!目前主频最高的手机 CPU 之一,高通骁龙 845有 2.8GHz 的处理能力[参考 2] ,一共是 8 核。

如不计算安卓系统、显示刷新、网络 IO 等 CPU 操作的话,每条信息能分配到的计算能力是:

这是什么概念?全球第一款微处理器是 1971 年英特尔推出的 Intel 4004[参考 3],这个老古董的主频也有 108KHz 啊。所以 21.9KHz 就是啥也干不了。

幸好 IT 界有个摩尔定律: 每 18 个月 CPU 性能就能翻倍(或者价钱是一半)。虽然现有科技已经很难让主频提升(某牙膏厂拼命挤也只有 5 Ghz)。

但假设我们使用了黑科技提升主频。等到了 2025 摩尔定律失效时[参考 4],我们的手机 CPU 主频应该达到:

看起来不错嘛,不过每条消息能得到的计算能力将达到:

呵呵,依然没有达到 Intel 4004 的水平,所以结果就是你等了 7 年,还是进不了这个全国群抢一个红包。

好吧,咱们让手机接入一个给力点的电脑, 比如说全球超算第一名的太湖之光,1 千万个 CPU 核心 [参考 5] 来帮忙处理这个宇宙第一大微信群。算力的问题总算有了着落。

我们假设平均每条消息有 10 个汉字,这大概相当于 30 byte,算上应用层会加上一定的控制字符,再加上 TCP/IP 网络层的数据消耗大概是 74 byte,取个整,平均每条消息有 100 byte,每个 byte 相当于 8 个 bit。

这时每秒需要的网络带宽大约是:

如果有人发红包,需要的带宽就更大了。

理论上,4G 网络能支持 1000 Mbps[参考 6],但别忘了,是全国人民在同一个群里,而你周围的人也需要同样的带宽,这使得你附近的基站不堪重负,陷入瘫痪。

为了避免网络瘫痪导致你抢不到红包或者看群消息,你需要搬到一个周围没有人的基站,比如放暑假了全校只有你还没回家的时候。

不过运营商的日子就不好过了,因为这一秒全国上下的流量就达到了惊人的:

这相当于 2017 年 4 月份的全国移动数据总流量的 65.7%[参考 7],意味着每 18 秒就能用完全国一年的流量。运营商瑟瑟发抖.gif

如果把 1.146 Ebit 数据用 2TByte 3.5 英寸硬盘(20 mm 高)装起来,然后叠起来,有 1433.25 m,相比之下,全球最高楼——迪拜的哈里发塔只有区区 828m。

当然,如果确实有需要,我相信电信运营商们肯定砸下重金为你建设全世界最大的宽带网络。

不过,接下来该花钱的就不是运营商——而是腾讯了。

为了处理这 1.146 Ebps 的流量, 腾讯需要准备 11466 万套交换机和服务器。

目前一台大厂 4 口万兆交换机售价大约是 4000 元,一台便宜带万兆口的服务器则大概需要 10000 元,这两项加起来的费用是:

呃,仅仅这两项就相当于 深圳 2014 年全年的 GDP[参考 8]。

这里还不包括网线、电线、服务器机架、机房托管、电费、运行支出……

这么多设备的存放也是个问题。一台带万兆(10Gbps)口的 2U 服务器有 88.9 mm 高,这样叠起来就有:

这差不多是中国到美国的飞机航线距离啊,用来修铁路也是够够的了。

好了,有了这么多设备加持,这下你终于可以愉快地进了群。

但你惊讶地发现,屏幕上除了白色,什么都没有——这是因为你的眼睛没办法接收这么快的数据!

人眼的视觉暂留时间是 100-400 毫秒[参考 9] ,而我们这个群每秒钟就要显示 102 万条信息,每条消息停留的时间只有大概 0.001 毫秒。相比之下,电影、电视都有 41 毫秒。

因此你还没来得及看清消息,它就已经消失了,最后只留下一团白色的色块在屏幕的正中央。

网友留言:

@大哥有柔情:

14 亿在一个群并不可怕。可怕的是,每逢节日群里都会让群主发红包!

@后知后觉:

已经做到了,14 亿人拉到一个微信群,大家看到的都是新闻联播。

@bluecat:

简单的说,你的手机会马上崩溃,因为它承载不了一秒钟的信息量。

@三毛鱼

可以实现,不过要加几条限制:

①所有微信账号强制加入到这个微信群。

②微信群只能有限的几个人发言,其他人不能发言。

③微信群里只能在每天固定时间段发消息。

④其他微信群在固定时间不能发消息,或者只能转发这个微信群的消息。

这样就可以实现了,技术上没有难度。

@程墨Morgan

“拉”到一个群里没啥不难实现的,反正用户信息都在服务器上,建一个包含所有用户微信号的群也就是添加一个记录而已。

但是,这个群千万不要让任何人都能发言,就以我国人民的多样性,各种话唠、贴图狂人、广告狂人……海量信息瞬间就可以把服务器、运营商网络和你手机的电池击溃。

@世安先生

讲真,单从理论上来说目前的技术还是可行的,咳咳,我要装逼了。

看了别的答主的回答,说人、终端、传输、处理、存储、分析等等各方面均有缺陷或者短板,跟不上大批量的数据,其实个人觉得实施起来也还是有得搞的,只是成本和利润之间的关系罢了。

首先,得考虑人的因素,多少多少亿的信息量对于某个特定个体来说价值无限接近于 0,我个人根本不关注这些信息,因为获取信息的效率太低了。

这就导致了百分之九十九的人直接忽略了这个群的存在,剩下的每天这个群里的消息无非就是置顶公告,置顶新闻,红包和闲聊斗图,浏览公告和新闻。

考虑到并发的问题,一般现在的服务器都可以做到,毕竟有大把的新闻 App 都可以做到;红包,做个算法随机分配吧,也别抢了,抢会严重影响体验,给十亿用户随机分配一段数据应该难度也不太大。

剩下的就是斗图闲聊,数据直接云存储在服务器端,分析处理总结出来个中心思想每多少秒多少秒推送给个人用户一次,就差不多了,需要详细信息的上服务器检索,个人觉得对个人终端的压力也不会太大。

其次,传输,这是我觉得问题最小的一个环节,为什么呢?解决了个人终端的问题之后,个人的数据传输量并不大,现有的传输网络完全可以满足。

服务器端的传输,要看这服务器怎么个建法,如果集中式处理和存储,就只能用百 G 专线,建个三五条完全够了。

只不过相应的配套交换机路由器要建一套庞大的系统出来。如果是分布式存储和处理,10G 的甚至 GE 的专线都够。这是传输。

第三,处理,如果非得把大批量的数据集中处理,就得建设一套国内最大甚至世界最大最复杂的数据中心才能够承载这套系统。

但是如果分布式处理的话,我相信现在的系统也够用,毕竟现有的运算量已经这么大了,而有这个群之后数据量也绝对不会爆炸式增长。

第四,存储,处理的工作能够完成存储肯定也不是问题,甚至可以将数据破碎后存储在个人终端上,将投资设备的矛盾转嫁到数据安全和管理上。

第五,数据分析,这一点才是重中之重,难点中的难点,如何有效的分析提取如此大量数据中的有用信息并推送给特定的个人才是核心关键。

虽然现在技术还没有大面积商业化,但我相信这种技术是肯定已经有试用的甚至是已经商用的存在了,只不过公众不太清楚而已,毕竟这种东西仔细想想还是有点恐怖的。

总之,如何实现这个系统或者说建好这个群,无非就是做好需求与资源之间矛盾的转嫁,把存储需求量大与投资大之间的矛盾转嫁到数据安全与运营管理上,把大数据量传输分散化,把大量的数据进行分析提取后定向推送,最核心的投资也就是整套智能有效的大数据分析系统。

(ಥ_ಥ)不过……话说这么搞的话不就是搞了个有 14 亿关注量的公众号嘛…d(ŐдŐ๑)好了,我装逼装完了,你们打的时候下手轻点,别拿砖头,别提 40 米青龙偃月大关刀……

转载于公众号“程序猿DD”


北京云中融信网络科技有限公司(简称融云),是安全、可靠的全球互联网通信云服务商,向开发者和企业提供即时通讯和实时音视频通信云服务。iResearch 艾瑞权威数据报告显示,融云即时通讯云市场份额连续多年稳居头位。

融云构建了一张覆盖全球所有国家及地区(共 233 个)的通信云网络,在全球各地设立多个数据中心及数千个加速节点。基于客户业务需求,融云可提供多种部署模式——公有云、私有云、混合云,为全球企业提供稳定的互联网通信云服务。针对企业级用户,融云将业务垂直到各个行业,为社交、直播、金融、交通运输、教育、电商、医疗等多个行业领域推出了针对性解决方案。

融云基于海量业务的技术锤炼,从基础架构到精细化运营,充分体现平台实力;凭借卓越的产品和优质的服务,在开发者规模、行业覆盖率、平台日活跃用户数、日均消息量等方面超越全行业。目前,已有数十万互联网用户及上千家企业级用户通过融云实现了场景化沟通,并从中获益,包括工商银行、中国移动、四川航空、CCTV 微视、中联重科、58 赶集、大河报业、新东方、陆金所、融创地产、IDG、华兴资本、易车网、猪八戒、得到 APP、荔枝、汽车之家、哈啰出行、百姓网、StarMaker、Opera、Elelive。

为什么不建议在代码中使用 User 这个单词?

科技创新王叫兽 发表了文章 • 0 个评论 • 76 次浏览 • 2021-05-14 15:24 • 来自相关话题

当你意识到你在项目开始时做的轻量、简单的设想竟然完全错了时,你已经用了六个月的时间投入到这个项目上。现在你需要解决这些问题,才能让这个系统继续运行下去,你发现你用在这个项目上的精力远远超出了你的预期,如果一开始就用正确的方式来做,就不会发生这样的事。今天,我要... ...查看全部

当你意识到你在项目开始时做的轻量、简单的设想竟然完全错了时,你已经用了六个月的时间投入到这个项目上。现在你需要解决这些问题,才能让这个系统继续运行下去,你发现你用在这个项目上的精力远远超出了你的预期,如果一开始就用正确的方式来做,就不会发生这样的事。

今天,我要告诉你的是一个经常犯的错误,一个会给你带来无穷无尽的问题的单词,那就是“users”。

这个单词有两个最基本的错误:

1.对你的需求来说 “User” 几乎从来都不是一个好的描述。2.“User” 会导致一个基本的设计安全缺陷。“user” 的概念是模糊不清的,使用更精准的术语几乎总是能起到更好的效果。

你没有使用者

最开始,没有任何一个软件系统真的有使用者存在。乍一看“user”是一个好的描述,但是你稍微一想就会意识到你的业务逻辑实际上比这要复杂的多。我会使用三个例子,从一个极端的情况出发。机票预订系统没有“users” 我曾经给机票预订系统写过访问控制逻辑,下面只是一小部分需求:

1.旅客可以使用预定记录码通过网站查看预定信息。

2.购买者可以通过信用卡号后四位数在网站上修改预订信息。

3.旅行社可以查看和修改他们的预订。

4.航空公司的值机人员可以根据角色和航空公司来查看和修改预订信息,这需要旅客提供身份信息。

不再一一列举。一些与人类相关的基本概念是“旅客”,“代理”(网站也可是看作代理)和“购买者”。“user”这个概念根本没用,并且在许多请求中我根本不会使用这个单词,举个例子,我们的请求必须包括旅客和代理人的证件,而不是使用者的证件。

Unix 没有 “users”

我们看一个不太一样的例子。Unix (这些天被称为POSIX)有用户,他们可以登录并执行代码。这样看起来很不错吧?我们深入看一下。

如果我们把所有都当作“users”的话,我们将会有:1.使用终端或者图形界面登录的人 2.像邮件或者web服务器这种系统服务也会以“users”的身份运行,例如nginx可以以httpd用户运行。3.在服务器上经常会有多人共享一个管理员账号用来SSH登录(例如,亚马逊的Ubuntu虚拟机默认SSH账号就是‘ubuntu’) 5.root 身份,和上面其他身份都不同。

上面四个是几乎不同的概念,但是在POSIX上他们都是 “users”. 一会儿我们就会看到,把这些概念都称为‘user’会导致很多安全问题。

在操作上,因为POSIX的用户模型边界存在,我们甚至不能找到一种方式说“只能让 Alice 和 Bob 通过这个账号登录”。SaaS 服务提供商没有 “users”

Jeremy Green 最近就用户模型在SaaS中的应用在推特上发文,它第一次提醒了我写下这篇文章,他的基本观点是

SaaS 服务几乎总是:

1.某个组织中的一个人支付服务费用。2.一个或多个人共同使用这个服务。如果你一开始就把这些人作为一个用户,你将会陷入一个痛苦的世界。你无法建立团队模型,你无法组建同时为多人支付的模型,然后你就会开始改造你的系统。现在你在SaaS案例中学到了一课,我们来看一看你的生活。

但是这只是众多例子中的一个:“users”的概念太模糊了。如果你开始怀疑“user”这个词,最终你可能发现最终你其实只需要两个概念:团队(用来组织关系和支付)和成员(实际使用服务的人)。“Users” 是一个安全问题 “user” 这个单词不仅是业务逻辑的问题,它也导致了一系列安全问题。

“user” 这个单词如此的模糊以至于从根本上将两个概念合并了:1.一个人。2.他们在软件中的代表性。

为了说明这个问题,假设你正在访问一个居心不良的网站,在它服务器上的图片导致了你的浏览器内存溢出。远程网站控制着你的浏览器,并且开始将你的文件上传到他的服务上。

为什么它能这样做?

因为浏览器是以系统用户的身份运行的,它被认为与人类身份的你相同,实际上你们是不同的。你作为’user’,不想上传文件。但是系统的账号也是‘user’,能够上传文件,如果浏览器运行在你的账号之下,他所有的行为会被当作是你的意图,也就是说是你让它这么做的,实际上不是。

这就是被称为Confused Deputy的问题。如果你使用“用户”这个词来描述两个根本不同的东西,那么这个问题就更有可能成为你设计的一部分。前期设计的价值

花更少的功夫处理相同的问题是成为高产程序员的关键。使用模糊不清的概念比如“用户”来组织你的软件,将会话费大量时间和精力来解决未来发生的问题。一上来就开始编码看起来是高产的,事实恰好相反。

下次你开始一个新的软件项目时,花几个小时预先确定你的术语和概念:你仍然不会完全正确,但你会做得更好。未来的你将感谢你所做的所有预防浪费的工作。