上古时代的应用

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

缺点：

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

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

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

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

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

996 时代的应用

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

优点：

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

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

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

互联网精神：小步快跑

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

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

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

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

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

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

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