社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
2017 年 8 月加入小米国际业务研发团队，后续深度参与到多个后端系统性能优化、架构改造。主导国际电商微服务架构演进，并产出基于 gRPC 的微服务框架，以及基于 traefik 的微服务 API 网关，积累了大量微服务架构经验。
2020 年 8 月受邀参加 GIAC 演讲，分享《如何用 Go 支撑海外电商架构演进》。
总的来说，从单体应用演进到微服务架构，主要有以下思路：
1. 垂直拆分。将不同功能拆分到不同微服务，同时区分高频功能和低频功能，合理分配资源。如：将电商中的搜索、商品详情、购物流程、订单、用户中心等功能拆分成独立的微服务。
2. 水平拆分。垂直拆分后，不同的微服务在底层可能有部分逻辑是通过引用公共库的方式来操作底层 redis、数据库等资源。此时如果开辟新的业务线，而新业务线需要启用新的服务，多个业务线都来操作同一份 redis 和数据库的话，容易导致数据不一致的问题，多个业务服务内也会存在重复实现的逻辑。而且后续扩展数据库、redis 数据结构时对各业务影响都较大。此时需要做水平拆分，将公共库的逻辑实现为独立的微服务提供给各业务线调用。也就是做分层设计，将公共逻辑沉淀成共享服务，向大中台、小前台方向演进。
3. 微服务治理。拆分成微服务后，服务间的调用关系变得复杂，排查问题难度也上升，需要引入服务治理手段。比如：服务注册和发现、负载均衡、限流和熔断、链路跟踪、日志和监控等。服务治理包括东西流量治理和南北流量治理。东西流量是指同一层的微服务间互相调用的流量，南北流量是高层应用调用低层服务的流量。东西流量主要靠微服务框架和 ServiceMesh 来治理，南北流量主要靠微服务 API 网关治理。
以下是 GIAC 演讲 PPT。
扫码关注微信公众号
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
