白话微服务 —— 大厂是怎么玩的？

Java学习：Java从入门到精通总结

Spring系列推荐：Spring源码解析

绝对不一样的职场干货：大厂最佳实践经验指南


最近更新：2022年3月23日

个人简介：通信工程本硕、Java程序员。我的故事充满机遇、挑战与翻盘，欢迎关注作者来共饮一杯鸡汤

点赞 收藏 ⭐留言 都是我最大的动力！

想必微服务这个词大家肯定都听说过，在开发层面，微服务这种架构模式很好地保证了项目与项目之间的独立性，也是各大厂如今使用的主流设计思路。

项目应用了微服务之后，就代表了一种糙、快、猛的开发模式

微服务搭配敏捷编程，就带来了如今的996加班和严重化的内卷，因为他们能让项目开发效率快上一个台阶，从应用的发展就能看出。

上古时代的应用

用户访问请求通过各级负载均衡到达了反向代理层，反向代理层会把访问请求转到服务器集群中，这就是经典的单体应用 + 水平扩展

缺点：

1. 牵一发而动全身
   每台服务器部署的代码都一样，每一个小的改动都很有可能影响到其它的功能点，所以每次改动都要做一个全链路回归

2. 回滚很痛苦
   所有代码一起上线一起回滚，就有可能出现我写好了一个功能，但因为别人的bug而被回滚了

3. 发布周期长
   平均半年才发布一次版本，无法快速适应市场需求

4. 应用复杂度很高
   ○ 代码会被混用，写的一个基础代码可能会被各个服务方共同使用，小的改动可能带来意料之外的影响。
   ○ 数据访问混乱，数据可能会被单体应用里的各个应用所引用（底层数据未做隔离的代价）

这一类代码也就是程序员们经常调侃的“屎山”，谁也不敢碰的代码

996时代的应用

当引入了微服务的架构之后，应用也来到了996的时代，此时，每一个服务器部署的应用都不一样，每个应用的底层数据库也是不同的，这就避免了底层数据模型的混乱

优点：

1. 小步快跑
   每个应用都可以做独立演进、独立部署、快速迭代

2. 团队赋能
   每一个微服务背后都有一个微服务的团队，包括前端、后端、测试等完整角色，这种情况下开发团队的话语权肯定要高于传统瀑布模型团队的

3. 边界清晰
   ○ 服务拆分：以大化小
   ○ 体现了分治思想：三高应用

互联网精神：小步快跑

那么在微服务的架构下，大厂里的团队组成是什么样的呢？

• 一般团队成员都是小规模，同时Leader也并不是专门管人的角色，可写代码可和产品拉扯

• 阿里系都是小规模的微服务团队，比如订单域，订单和支付系统的对接可能由一个团队来负责，订单状态流转又是另一个团队来负责

• 在每个精英团队都会做双备份机制，重沟通，轻文档，业务知识的积累一般是沉淀到个人，因此每个开发人员在自己业务线上积累的知识非常重要，快速定位问题、解决线上问题都需要这个人来参与，对每个重要功能点都会指定一个Feature Owner，同时还会指定一个Backup，保证有两个人能做线上的支持

• 测试人员：阿里系推崇开发自测，功能和质量保证完全由个人承担。测试同学致力于测试平台、效能平台的搭建。对于功能性测试来说，一般不指派到各个团队中，而是指派到中间的职能方，它可能是支持当前事业部或多个团队的测试需求，从集成测试的角度衡量质量保证的计划

从上面的团队架构也能看出来，每个人的代码能力都是硬指标，只会测试或CRUD的程序员在职场上的生命周期都很短

同时，架构师作为“设计师”的角色，阿里系大量采用了跨团队架构师的职责，因为架构师要有整体视角，所以要有整体的业务方向视角，同时还有其他的职能团队负责一些特殊的业务，比如为应用搭建手机端页面等等