宝宝架构路(一)

2019/01/23 Infrastructure

宝宝架构路(一)

背景

微服务,核心概念就是组件化思想,通过用小的组件化服务,以轻耦合的模式去构建大型的网络应用。

借鉴网易云[0]的观点,一个完整微服务体系应该包括API网关(流量分发、降级、熔断)、容器化(支持弹性横向扩容)、网络规划和治理(服务注册、发现、鉴权、网络拓扑)、DevOps(开发工具链: 代码、发布、构建镜像)、分布式链路追踪(全链路、报警、监控、故障定位分析) 和 自动化测试(API测试、压测)。

我觉得这个描述还是很全面化的,对于将团队业务或是自己的个人项目进行微服务应用,也应该是,在一个合适的阶段,从上面这些方面,从于合理的切入点,进行微服务改造,而不应该为了微服务而微服务。

关于分布式链路追踪的一点实践经验

就本宝宝来说,在我毕业入职之后,工作主要是对所在团队(核心风控)进行基础架构方面的优化升级。我自己参与了的,是分布式链路追踪这一环的开发和实现。基于团队的主要技术栈是Python(服务框架 Flask + Celery),我们的解决方案是基于Google的一篇分布式追踪论文Dapper[1]来实现全链路的嵌入。Google对这篇论文有一个相应的开源工具,Zipkin[2],我们自己对其进行改造,替换了封装框架、日志解决方案等,保留了context的机制。从而使得每次只需要对统一底层包的迭代更新,就可以对所有线上服务进行更新。但是弊端是,我们把链路代码嵌入了业务代码。

在改造过程中,我们也研究了美团的全链路解决方案[3],这种方案不需要把链路代码嵌入业务代码,而是在日志层面进行链路收集,但相应的,对日志格式化和规范化也提出了很高的要求。

这里有一个各个解决方案的对比:掘金-几种分布式调用链监控组件的实践与比较(一)实践[4]

关于服务注册与发现的一点调研

宝宝在团队Kubernetes容器集群化的道路上步履维艰,不过也好,对于团队来说是换技术债,对于宝宝来说是补技术栈。。。

如果没有合理的网络规划,在从传统服务器向K8S集群迁移的时候,最大的困难一定是ingress。所以宝宝才要来折腾一下服务注册与发现。

服务注册和发现,其实不是新话题了,当服务数量始终处于相对固定时,可以通过手动配置静态配置文件,维护Nginx的形式进行服务间的调用和通信。但是,在微服务中,弹性扩容已经是必不可少,微服务实例的网络位置发生变化是一种常态。在这个过程中,如果还要维护映射配置文件,对于运维来说就是灾难。所以,我们需要服务注册和发现机制。

通常的服务注册和发现分两种模式:

客服端发现模式

img

较少的网络跳转,但要嵌入业务代码。

服务端发现模式

img

不需要嵌入业务代码,集中在中央路由器或者负载均衡器做处理,但是需要对其搭配较高的基础设施环境。

目前比较流行的服务注册与发布解决方案,包括诸如 ZooKeeper、Etcd等的利用健值对存储建立服务发现系统,和Netflix的开源项目Eureka,以及HashiCorp公司的Consul。

关于选型,网上也有很多对比图,其中最重要的区别可能就是对CAP(Consistency、Availablility、Partition tolerance)[5]定理的选择了。具体的感悟,宝宝正在实践,等到有所产出和成果,再来写吧。

Next?

应该是服务注册与发现的实践体悟了吧,祝自己成功……

参考链接

Search

    Table of Contents