云妹导读:随着业务走向国际化、意想不到的挑战接踵而来——团队迎来一位位金发碧眼工程师,业务支持与优雅代码相互摩擦,沟通协作、研发模式、文化氛围,如何适应这些新的变化?今天,我们邀请Aliexpress高级技术专家许晓斌,分享他的解决之道。
背景
大约在5年前,也就是2013年我刚加入阿里的时候,那个时候 DevOps 的风刚吹起来没多久,有家公司宣称能够一天发布几十上百次,这意味着相比传统软件公司几周一次的发布来说,他们响应商业需求的能力可以甩后者几条街,而且这差距根本不是加班能赶上的。今天的 AliExpress 技术团队小几百人的规模,可一天发布几十次也已经司空见惯了,这主要得益于三个方面:
非常彻底地微服务化,拆分粒度很细,且旗帜鲜明地反对重二方库。
阿里集团整体的运维标准化,尤其是 Docker 技术的全面覆盖。
AliExpress SRE 团队不断努力保证稳定性。
然而,效能这个东西,你永远不会说:“够了,够快了”,尤其是在当下的消费型社会,人人都是消费者,而消费者恨不得脑子里的欲望刚闪现出来,你的商品或服务瞬间就到他面前。况且,随着我们不断国际化的步伐,新的因素必然会影响原来的高效能。
沟通带宽衰减问题
第一个因素是研发团队自身的发展和变化,今天的 AliExpress 技术团队已经是一个名副其实的分布式国际化团队,工作地是杭州+深圳+莫斯科+马德里+其他欧亚都市,外籍同学的比例是 15%,而且能看到这个比例会不断提高,新的国外工作地点也会增加。而这样的团队,对比在同一层楼里的一群中国人组成的团队,是有本质的区别的。
我们可以将人与人之间的沟通和网络通信做类比,我们知道网络通信是有带宽的,从早期的拨号上网几十K,到现在的家庭宽带主流的几十上百M,再到数据中心内部局域网内部G级别的数量级,带宽越大,能传输的信息也就越多(通常浪费也就越多)。而人与人之间沟通也可以认为是有带宽的,例如充分信任的全由中国工程师组成小团队,平时相互一起吃饭散步聊天,大家彼此都特别了解,沟通起来就特别顺畅,想到一个点子转个朝向说两句对方就懂了。可对于一个分布式国际化团队来说,这个沟通带宽可是衰减得厉害:
中文到英文的转换,衰减一次。对于大多数人来说,英语不是母语,沟通的效率自然会降低。
单地到多地,衰减一次。电话,视频,钉钉,都没有面对面沟通来的高效。(否则大家都不会不约而同地刷脸了)
时差,再衰减一次。杭州和莫斯科的时差是5个小时,所以基本上北京时间上午我们是联系不上莫斯科的同学的。
文化的差异,再衰减一次。例如很多我们可以用来增强感情的团建方法,撸串K歌王者吃鸡,外籍同学可能完全不感冒。
那有人可能会说,既然沟通成本这么高,那直接在一个地方全部招中国工程师多简单?这么做简单是简单的了,可都这么搞的话,怎么在全球范围吸引优秀的人才呢?更何况 AliExpress 的用户基本都是老外,这后面的人才如果全是中国人,听起来这生意就不太靠谱对不?谷歌微软亚马逊,哪家不是在全世界搜罗顶尖人才?
所以说,既然沟通带宽的衰减是难以避免的,那我们唯有把对这带宽的利用率提上去。具体我们已经做了,或者在做一些事情:
尽可能和行业主流技术接轨,降低工程师学习成本。我们基于开源 Spring Boot 做的阿里巴巴生态集成,摒弃 antx, webx, pandora,都是这个思路。
English First:注释,文档,工具,英文必选,中文可选。
服务发现,让所有微服务可见,增强自描述,可搜索。
拥抱 Kotlin
关于开发效率,我个人认为所有 Java 程序员都应该认认真真、仔仔细细去看下 Kotlin,因为这门语言太简洁了,而且和 Java 可以无缝互操作,完全具备生产环境使用的条件。
有关简洁,我这两天把一块 Java 代码改成了 Koltin,在丝毫不降低可读性的情况下(实际上可读性是提高了),代码行妥妥地减少了 1/3 。
此外我忍不住分享一下最近我基于 Sergey 的 Kotlin HSF DSL 写的一个将函数发布成 HSF 服务的功能:
只需要不到 15 行代码,就可以启动一个 Spring Boot 应用,把一个字符串小写的功能发布成 HSF 服务,大家可以对比下 Java 需要写多少东西。语言层面的升级,给框架,中间件,API设计带来更多的可能性,这就能使我们砍掉更多的所谓脚手架代码,让业务代码更精简,更优雅,进而带来效率提升。
作为程序员,如果只掌握一种语言,是非常危险的,因为这种语言的各种设计会禁锢你的思维。我自己会在业余看一些其他语言,不过在日常工作中基本也只能写 Java(如果 shell 也算一种语言的话,还是写过些 shell 的)。不过从现在开始,我会开始尽可能地用 Kotlin 写代码,我的团队也全面把日常编程语言从 Java 切换到 Kotlin,其实我们都已经不算 Early Adoptor 啦,雷卷在一年多前就已经不停在鼓吹 Koltin 并上线了一个应用,AliExpress 俄罗斯办公室的 Sergey 等同学也已经在生产用上了 Kotlin,Sergey 个人也在很多地方分享他的经验。
我们会推动 AliExpress 拥抱 Koltin,从语言层面来提升我们的效率。
阿里资深技术专家雷卷,在他最近的一篇谈程序员学习的文章中写了很多东西,我都是很认同的,其中一段话尤其想点赞:
不要和程序员谈自己的编程历史,很多经验今天已经不适用啦,可能有一些,但是会给别人带来甄别成本,别人也懒得来甄别。2-3年不关注技术,基本快和程序员和编程绝缘啦,不是绝对,但是通常不会错。
原文请看:程序员如何自我学习?阿里资深技术专家这样做
持续学习,与诸君共勉。
FaaS
Function as a Service,又一个新的 Buzz Word?是的,不过我还真的相信这个 Buzz Word,行业里 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服务相继推出,大家都在尝试把自己的业务往上面搬,这其中的道理在哪?
如果作为云服务提供商,这个道理是很显而易见。你的对手按照 docker instance 收费,2 core 4g 起,一小时多少钱;如果你能做到按调用次数收费,一小时内运行了 30 次。那这个价格差必然是数量级的,用这一招就可以秒杀对手了。
上面所说的纯粹是硬件成本的考量,但我们还需要从效率方面看这个事情。
首先由于 Function 天生是无状态的,而且是足够轻量的,那么理论上做到 ms 级别的 auto scaling 是没有问题的,例如 graalvm 就在这方面很有潜力。
ms 级别的 auto scaling 不仅能够大幅提升资源利用率,更是提升了运维效率,开发几乎就不再需要考虑容量的事情的。例如在双11的时候,我们做大量的压测,很大程度上是为了保证系统各个部分的水位在预测的安全的线上,如果做到了实时扩缩,那么当流量高峰来的时候再扩容好了。
什么是轻量?
今天很多工程师可能已经忘了轻量的概念是什么,大家就是各种侵入,写个简单的应用,打出来的 jar 包,业务代码的占比往往不到 1/10。
先不说这里可能无谓浪费了多少内存,无谓增加了多少启动时间。这个 client 那个 share 满天飞带来的最麻烦的后果就是,开发经常要做各种升级,而且一升就挂,一查就半天。打着所谓性能旗号的各种重客户端,就是反服务化的;各种缺乏细心设计的 API 导致的不兼容升级(而且是暴力推动,不升级卡发布),就是反工程师操守的。
微服务化做得好的,应该积累一大批轻量的接口,使用这些接口甚至都不需要引入什么 share/open/client 的依赖,直接用 HSF 的泛化调用即可,这样的接口才不对用户有代码侵入。
我们已经在 AliExpress 尝试(并已经上线)基于 Koltin DSL 和 HSF 泛化调用编写 Function,用户只需要依赖很简单的一个 FaaS SDK 就可以编写业务代码,基于前面提到的阿基米德服务发现,他可以快速重用现有服务,做一些聚合和过滤的操作,满足业务需求,这个在贴近无线的业务中非常有用。当然,这个尝试只是一个开始,但我们已经看到,其实有大量的业务逻辑(在 AliExpress 可能是 5/1 至 1/3)其实自身不依赖于数据,可以做成 Function,而且我们可以做到让这些业务不依赖任何业务二方库,甚至借助 Service Mesh 等技术,不依赖于任何中间件 client。这些业务的 owner 不需要关心各种乱七八糟的升级问题,不需要关心容量问题,真正地只关心自己的业务逻辑。
我认为这是 FaaS 该成为的样子,而我及我的团队,正不断努力去实现之。
了解更多