前言
题目有点大,哈哈,但是不影响各种骚骚的发挥。废话不多说,直接上干货。
对于当下平台的建设,在复杂的业务场景下,很多架构选型瞄准了微服务作为其技术实现方案。那么就衍生出了很多的流派。
大致上,根据社区的活跃程度,我们更多的依据国内的技术圈,分为三个流派:
- Dubbo 体系
- Spring Cloud 体系
- K8s 体系
那么,我们就这三个流派,详细做一个对比说明。
从根源入手
个人觉得学习要不能浮躁,要做到尽量求甚解,尤其是在技术的学习上。因此,我们了解选型的对比,那么尽量了解他们的解决的问题,以及其根源。
服务化框架和平台的选择,是搭建微服务架构的一个基础,就好比构建一栋大楼要打好地基一样,重要性是不言而喻的。
三个流派,分别是三个大厂,在实际业务背景下,搭建微服务架构,演进产生的解决方案。
Dubbo,是由阿里巴巴技术团队,在生产中实际应用的解决方案;
Spring Cloud,由netflix,则是Spring 成熟的框架,演变出的微服务架构解决方案;
Kubernetes(K8S),是由谷歌技术团队,在生产中,应用的解决方案。
三者,对于微服务架构的问题解决、抽象层级,在某些地方会有不同,所以我们需要细细的看,聊。
他们产品中的一些功能也可能是重叠的,排他的,所以选型中,要理解之后,慎重选择。
微服务架构关注的点
随着业务规模的升级,架构模式也随着升级,为了让技术开发人员,更加关注业务的开发,因此微服务架构产生。
微服务架构提供了一系列的基础设施能力的支撑,省去了技术开发人员的对于公共设施能力的关注,专注于业务开发。
那么,了解微服务架构公共关注点,也就能了解,微服务架构包含的技术设施,才能更好的抉择选型。
简而言之,我们对微服务公共关注点,作出以下分类:
- 配置管理
- 服务发现与复杂均衡
- 弹性和容错
- API管理
- 服务安全
- 日志监控
- 链路监控
- Metrics监控
- 调度和发布
- 自愈和自动伸缩
三个流派的对比
了解了,微服务架构中那些关注点之后,我们对三个流派分别针对上述关注点做一个横向对比。
Dubbo |
SpringCloud | K8s | |
配置管理 | Diamond/Nacos | Spring Cloud Config | ConfigMaps/Secrets |
服务发现与复杂均衡 | Zookpeer/Nacos+client | Eureka+ribbon | Service |
弹性容错 | Sentinel | Hystrix | HealthCheck/ServiceMesh/Probe |
API管理 | 无 | Zuul/Spring Cloud Gateway | Ingress |
服务安全 | 无 | 无 | 容器安全 |
日志监控 | ELK | ELK | EFK |
链路监控 | 无 | Sleuth | Jaeper |
Metrics监控 | Dubbo Admin/Monitor | Actuator/MicroMeter+ Prometheus | Heapster/Metrics-Server+Prometheus |
调度和发布 | Jar/War | Jar/War | Docker Image/Helm |
自愈和自动伸缩 | 无 | 无 | AutoScaler |
了解了,大致上他们在微服务架构解决方案中的一些实现之后,我们再看优劣比对
Dubbo,亮点是由国内公司阿里巴巴背书,且实际业务中脱产,成熟稳定,RPC高性能支持流量治理,不足之处为耦合度高,更新迭代慢,国外社区小,仅支持JVM运行
SpringCloud,由Netflix 背书,国外社区活跃,程度高,不足之处,JVM运行,耗资源
K8s,由谷歌技术团队背书,技术稳定,省去了很多的技术实现,但是运维门槛高,学习成本大,问题解决复杂
个人建议
综合上述我们聊得,其实没有一成不变的,架构师需要根据实际的公司情况,技术团队能力以及产品业务背景,抉择自己的架构选型。综合来说,K8s,从目前个人使用出发,是个人比较看好也是会优中考虑的。