画外音：终于，你能一次性看到完全体了。
负载均衡、数据收集、服务发现、调用链跟踪。这些非业务的功能，一般是谁实现的呢？
（1）互联网公司一般会有一个“架构部”，研发框架、组件、工具与技术平台；（2）业务研发部门直接使用相关框架、组件、工具与技术平台，享受各种“黑科技”带来的便利；框架、组件、工具与技术平台的使用与推广，往往会遇到以下一些问题：（1）业务研发团队，需要花大量时间去学习、使用基础框架与各类工具；（2）架构部，对于“黑科技”不同语言客户端的支持，往往要开发C-client，Python-client，go-client，Java-client多语言版本；（3）架构部，“黑科技” client要维护m个版本， server要维护n个版本，兼容性要测试m*n个版本；（4）每次“黑科技”的升级，都需要推动上下游进行升级，这个周期往往是以季度、半年、又甚至更久，整体效率极低；
（1）一个进程实现业务逻辑（不管是调用方，还是服务提供方），biz，即上图白色方块；
（2）一个进程实现底层技术体系，proxy，即上图蓝色方块；画外音：负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。（1）biz和proxy共同诞生，共同消亡，互为本地部署，即上图虚线方框；（2）biz和proxy之间，为本地通讯，即上图黑色箭头；（3）所有biz之间的通讯，都通过proxy之间完成，proxy之间才存在远端连接，即上图红色箭头；这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：
整个服务集群变成了网格状，这就是Service Mesh服务网格的由来。Service Mesh的行业开源最佳实践是什么？
画外音：具体envoy，mixer，citadel，pilot和galley的职责与细节，见《大专栏》。前面所有章节讲的都是单机房架构，单机房架构的特点是什么？架构分层之间，是同连接，即：站点，服务，数据全部单元化，仅连接同机房。（2）如果不能“单元化”，跨机房的数据同步存在较大延时；站点，服务，数据做不到全量单元化，做不到“只”连接同机房，但可以“最小化”跨机房连接，整个架构，可以只有两个地方跨机房：机房区分主次，落地性强，对原有架构冲击较小，业务几乎不需要进行单元化改造。18次直播回看，以及《架构师第九阶：架构进阶》的6节也已经放出，系统性的详聊了上面这些问题，感兴趣的同学可以扫码看细节。18次直播精华回看，有哪些内容？
每次1-2小时不等，全部已放出。
第一阶：技术选型（5节，已放出）
第二阶：接入层架构（5节，已放出）
第三阶：极速性能优化（3节，已放出）
第四阶：微服务架构（7节，已放出）
第五阶：数据库架构（6节，已放出）
第六阶：缓存架构（7节，已放出）
第七阶：架构解耦（6节，已放出）
第八阶：架构分层（5节，已放出）
第九阶：架构进阶（6节，已放出）
把控住这些，应该能成为一名P8的架构师吧？
扫码领券，直减100，3.1之前
白嫖了这么多年，欢迎为情怀补票，希望大家有收获，早日成为P8P9架构师。
