本文概述了微服务架构的复杂性,涉及开发、支撑服务及多层级体系,包括接入层、基础设施层、网关层、业务服务层、支撑服务层等。强调了网关在微服务中的核心作用,如反向路由、安全认证、限流熔断等。还探讨了配置中心在微服务中的重要性,用于实时更新配置信息。比较了RPC与HTTP两种通讯方式,并强调了服务治理的重要性,包括高可用、负载均衡、监控、限流熔断等功能。最后,指出微服务架构的灵活性和多样性,以及对微服务体系认知的重要性。
微服务的技术架构体系涉及到比较多的内容,除了业务代码的开发以外,还需要很多的支撑服务。每个公司都有自己的微服务架构体系,虽然在细节上有很多不同,但是整体的思路是类似的,下图展示了一个比较成熟的微服务架构体系。
对一些成熟的互联网公司来说,其内部都有一个成型的互联网体系,当然不是所有的公司都这么的完善了。对BAT级别的来说,他们内部的体系则比图中还要的细致。
最上面的一层叫做接入层,主要是负载均衡器把外部的流量接入到平台内部中来
最下面的一层叫做基础设施层,一般由运维团队来维护的
最上面的一层和最下面的一层与运维团队比较紧密。
而其中间的部分与微服务体系比较密切。
网关层:是微服务体系中比较核心的部分,有无线网关,第三方应用网关,开发平台网关
业务服务层:一个是聚合层,一个是基础层
支撑服务层:包含,服务注册发现,配置中心,容错限流,监控报警
平台服务:现代的技术团队已经开始引入新的发布体系,如Kubernets
总共有6层体系,这6层体系一般是微服务体系的标准化模板,下面我们将深入相关的技术,不建议初创公司,上去就投入到微服务体系中去。
下面我们对其中关键的几个体系进行讲解:
微服务网关层
为甚要引入网关呢?在我们居住的小区中是不是只有几个门,而在大门旁一般都有门卫,像API网关也相当于门卫,我们的系统中有很多的微服务,但是又不想让这些微服务暴露给客户,这个时候网关就可以屏蔽掉内部的细节。客户只需要访问网关就可以了。
最好将网关部署为无状态的,这个时候可以部署多台,更容易的实现集群。网关在其中承担的功能:
反向路由:当外面的请求进来的时候,如何找到具体的服务,这就是反向路由
认证安全:有些是正常访问,有些是恶意访问,需要网关进行辨别
限流熔断:比如说小区的大门突然进来了很多人,这个时候最好对大门进行限流,防止内部过度拥挤。
日志监控:外面的请求去访问内部的服务,那么就要对东西做一些审计,分析调用的性能情况,对整个服务流量进行监控
目前社区的关于 API Gataway 的项目:
Tyk:Tyk是一个开放源码的API网关,它是快速、可扩展和现代的。Tyk提供了一个API管理平台,其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。
Kong:Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行,通过插件扩展,它提供了超越核心平台的额外功能和服务。
Orange:和Kong类似也是基于OpenResty的一个API网关程序,是由国人开发的,学姐也是贡献者之一。
Zuul:Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。具有很灵活的路由过滤功能
apiaxle: Nodejs 实现的一个 API 网关。
在Java体系中,一般会选用Zuul作为网关。
参考:
微服务配置中心
配置中心在微服务体系中有什么样的作用呢?想想如果没有配置中心,很多的公司刚开始都没有配置中心的概念,开发人员一般把配置放在配置文件中,并且每个人的做法都不一样,另外一个就是如果需要修改配置的时候都要重新发布服务,还有如果没有集中式的配置的话,我们也不知道到底是谁修改了配置。
那些东西东西可以作为配置呢?
连接字符串,数据库连接地址,缓存连接地址,MQ连接地址
动态调整参数,如超时,限流的阈值
业务的开关,某个功能只对某个地区生效
如果通过发布去配置这些东西,将会耗时很长,而通过配置中心,则是十分的灵活。所以微服务架构中一定要有一个配置中心。
应用连接到配置中心,可以实时的更新配置,可能是实时的拉取,也有可能是配置中心服务器推送,两种做法各有利弊。
拉配置的话可能无法实时更新
推的话可以实时更新,但需要配置中心性能较高
目前已经开源的常用配置中心服务器:
Apollo 携程开源
Spring Cloud ConfiServer Spring的全家桶组件
Disconf 百度
参考:
微服务通讯体系
微服务中比较典型的两种通讯方式,RPC与Http两种方式各有优劣,这里我们对两种通讯方式做一个比对
那么如何根据自己的业务场景进行选择呢?
RPC性能优于REST 但是RPC不方便调试
REST可以直接上手,基于常见的HTTP协议
一般开发语言都会支持REST,而堆RPC需要额外的支持,REST对开发人员比较友好
参考:
微服务的服务治理
当一个国家人多了,需要政府来进行管理,东西多了,也需要进行管理分类,在微服务体系中,如果服务多了,需要管理和治理。那么一个好的微服务体系,需要关注那些点呢?
1 首先需要知道服务的集成
2 服务要提供高可用,负载均衡的功能
3 服务需要能路由
4 对微服务进行监控,调用链监控,系统指标监控,后期用于定位问题
5 限流熔断,也是保证微服务高可用的一种方式
6 好的微服务框架如果能同时支持两种调用方式RPC与REST就很不错
7 最后需要文档来记录服务中的各种重要内容,方便新人快速了解系统。
以上是设计的时候要考虑到的点。主要是保证服务的可用性,健壮性,扩展性,以及易用性上。一般服务治理的框架都会提供这些功能:服务降级、服务流控、服务动态扩展、超时控制、优先级调度、负载均衡策略调整
市场上有关服务治理的框架:
部分小公司会选择Dubbo,或者eureka作为自己的服务治理框架,稍具规模的公司可能会选择自研相关框架,只需要具备上述的功能就行了。
最后
这里有关微服务的技术架构体系,我们主要说了一些服务相关的东西,服务可以类比成人,而人是需要有衣食住行的,配置中心,通讯,治理,就是服务的必备存活条件。微服务体系可以衍变为多种多样的形式,主要对微服务的体系有个认知,这样在公司快速发展的过程中仍然能从容应对。
注:
本文独家发布自金蝶云社区