- 选型准则
- 生产级:选择的产品是要抗流量解决实际业务问题的,并非只是拿来写demo,该产品必须是可运维、可治理,成熟稳定的。
- 一线互联网公司落地产品
- 开源社区活跃度
- 微服务基础架构核心关注点
- 服务框架选型
- SpringBoot/Cloud由于spring社区的影响力以及Netflix的背书,目前可以认为是Java微服务的一个社区标准。基于Spring的框架本质上可以认为是Restful框架,序列化协议主要采用基于文本的JSON,通信协议基于HTTP。
- Dubbo,其本质是一套基于Java的RPC框架,当当的DubboX拓展了RESTful的接口暴露能力,它主要面向Java技术栈,跨语言能力较弱,其强大的服务治理能力也导致了框架相对较重,完全用好的门槛较高。另,新浪微博开源的Motan也不错,像是一个轻量剪裁版的Dubbo。
- gRpc,是谷歌近年新推的一套RPC框架,基于protobuf的强契约编程模型,能自动生成各种语言客户端,且保证互操作。支持HTTP2是一大亮点,但比较适合内部服务调用场景,对外暴露服务比较麻烦,需要配合gRpc gateway,另,东西比较新,对于HTTP2带来的好处社区也未达成一致,请慎用。
- 运行时支撑服务选型
- 服务注册中心,springcloud与Euark是最佳搭配,Eureka在Netflix经过大规模生产验证,支持跨数据中心,客户端配合Ribbon可以实现灵活的客户端软负载;Consul[附录12.5]也是不错选择,天然支持跨数据中心,还支持KV模型存储和灵活健康检查能力,目前在github上有超过11k星
- 服务网关,如果采用Spring Cloud体系,则选择Zuul[附录12.6]是最佳搭配,Zuul在Netflix经过大规模生产验证,支持灵活的动态过滤器脚本机制,异步性能不足(基于Netty的异步Zuul迟迟未能推出正式版)。Zuul网关目前在github上有超过3.7k星。基于Nginx/OpenResty的API网关Kong[附录12.7]目前在github上比较火,有超过14.1k星。因为采用Nginx内核,Kong的异步性能较强,另外基于lua的插件机制比较灵活,社区插件也比较丰富,从安全到限流熔断都有,还有不少开源的管理界面,能够集中管理Kong集群。
- 配置中心,Spring Cloud自带Spring Cloud Config[附录12.8](github 0.75k stars),个人认为算不上生产级,很多治理能力缺失,小规模场景可以试用。个人比较推荐携程的Apollo[附录12.9]配置中心,在携程经过生产级验证,具备高可用,配置实时生效(推拉结合),配置审计和版本化,多环境多集群支持等生产级特性,建议中大规模需要对配置集中进行治理的企业采用。Apollo目前在github上有超过3.4k星
- 服务监控选型
- 日志监控,ELK目前可以认为是日志监控的标配,功能完善开箱即用,Elasticsearch[附录12.10]目前在github上有超过28.4k星。Elastalert[附录12.11] (github 4k stars)是Yelp开源的针对ELK的告警通知模块。
- 调用链监控,目前社区主流是点评CAT[附录12.12](github 4.3k stars),Twitter之前开源现在由OpenZipkin社区维护的Zipkin[附录12.13](github 7.5k stars)和Naver开源的Pinpoint[附录12.14](github 5.3k stars)。
- Metrics监控主要依赖于时间序列数据库(TSDB),目前较成熟的产品是StumbleUpon公司开源的基于HBase的OpenTSDB。OpenTSDB 本身不提供告警模块,Argus[附录12.17](github 0.29k星)是Salesforce开源的基于OpenTSDB的统一监控告警平台,支持丰富的告警函数和灵活的告警配置,可以作为OpenTSDB的告警补充。年也出现一些轻量级的TSDB,如InfluxDB[附录12.18](github 12.4k stars)和Prometheus[附录12.19](github 14.3k stars),这些产品函数报表能力丰富,自带告警模块,但是分布式能力不足,适用于中小规模企业。Grafana[附录12.20](github 19.9k stars)是Metrics报表展示的社区标配。
- 健康检查和告警通知,Sensu[附录12.21](github 2.7k stars),能够对各种服务(例如spring boot暴露的健康检查端点,时间序列数据库中的metrics,ELK中的错误日志等)定制灵活的健康检查(check),然后用户可以针对check结果设置灵活的告警通知策略。Sensu在Yelp等公司有落地案例。其它类似产品还有Esty开源的411[附录12.22](github 0.74k星)和Zalando的ZMon[附录12.23] (github 0.15k星),它们是分别在Esty和Zalando落地的产品,但是定制check和告警配置的使用门槛比较高,社区不热,建议有定制自研能力的团队试用。ZMon后台采用KairosDB存储,如果企业已经采用KariosDB作为时间序列数据库,则可以考虑ZMon作为告警通知模块。
- 服务容错选型
- 针对Java技术栈,Netflix的Hystrix[附录12.24](github 12.4k stars)把熔断、隔离、限流和降级等能力封装成组件,任何依赖调用(数据库,服务,缓存)都可以封装在Hystrix Command之内,封装后自动具备容错能力。
-
Hystrix一般需要在应用端或者框架内埋点,有一定的使用门槛。对于采用集中式反向代理(边界和内部)做服务路由的公司,则可以集中在反向代理上做熔断限流,例如采用nginx[附录12.25](github 5.1k stars)或者Kong[附录12.7](github 11.4k stars)这类反向代理,它们都有插件支持灵活的限流容错配置。Zuul网关也可以集成Hystrix实现网关层集中式限流容错。集中式反向代理需要有一定的研发和运维能力,但是可以对限流容错进行集中治理,可以简化客户端。
- 后台服务选型
- 消息系统,Apache顶级项目Kafka[附录12.26](github 7.2k stars)是社区标配。对 Kafka的监控和治理能力进行适当定制完善,Allegro公司开源的hermes[附录12.27](github 0.3k stars)是一个可参考项目,它在Kafka基础上封装了适合业务场景的企业级治理能力。阿里开源的RocketMQ;RabbitMQ[附录12.29](github 3.6k星)是老牌经典的MQ,队列特性和文档都很丰富,性能和分布式能力稍弱,中小规模场景可选。
- 缓存治理,客户端直连模式,SohuTv开源的cachecloud[附录12.30](github 2.5k stars)是一款不错的Redis缓存治理平台,提供诸如监控统计,一键开启,自动故障转移,在线伸缩,自动化运维等生产级治理能力,另外其文档也比较丰富。中间层Proxy模式,则Twitter开源的twemproxy[附录12.31](github 7.5k stars)和CodisLab开源的codis[附录12.32](github 6.9k stars)是社区比较热的选项。
- 分布式数据访问层,采用Java技术栈,则当当开源的shardingjdbc[附录12.33](github 3.5k stars)是一个不错的选项,如果倾向采用数据库访问中间层proxy模式,则从阿里Cobar演化出来的社区开源分库分表中间件MyCAT[附录12.34](github 3.6k stars)是一个不错选择 。
- 任务调度系统,xxl-job[附录12.35](github 3.4k stars),部署简单轻量,大部分场景够用。elastic-job[附录12.36](github 3.2k stars)相比xxl-job功能更强一些也更复杂。
- 服务安全选型
- 对于微服务安全认证授权机制一块,目前业界虽然有OAuth和OpenID connect等标准协议。
- Apereo CAS
- Boss开源的keycloak[附录12.38](github 1.9 stars),spring cloud security[附录12.39]等,大都是opinionated(一家观点和做法)的产品,同时因支持太多协议造成产品复杂,也缺乏足够灵活性。
- 个人建议基于OAuth和OpenID connect标准,在参考一些开源产品的基础上(例如Mitre开源的OpenID-Connect-Java-Spring-Server[附录12.40],github 0.62k stars),定制自研轻量级授权服务器。
- Wso2提出了一种微服务安全的参考方案[附录12.45],建议参考,该方案的关键步骤如下:
-
使用支持OAuth 2.0和OpenID Connect标准协议的授权服务器(个人建议定制自研);
-
使用API网关作为单一访问入口,统一实现安全治理;
-
客户在访问微服务之前,先通过授权服务器登录获取access token,然后将access token和请求一起发送到网关;
-
网关获取access token,通过授权服务器校验token,同时做token转换获取JWT token。
-
网关将JWT Token和请求一起转发到后台微服务;
-
JWT中可以存储用户会话信息,该信息可以传递给后台的微服务,也可以在微服务之间传递,用作认证授权等用途;
-
每个微服务包含JWT客户端,能够解密JWT并获取其中的用户会话信息。
-
整个方案中,access token是一种by reference token,不包含用户信息可以直接暴露在公网上;JWT token是一种by value token,可以包含用户信息但不暴露在公网上。
- 服务部署平台选型
容器已经被社区接受为交付微服务的一种理想手段,可以实现不可变(immutable)发布模式。一个轻量级的基于容器的服务部署平台主要包括容器资源调度,发布系统,镜像治理,资源治理和IAM等模块。
- 集群资源调度系统,目前Google开源的kubernetes已经形成市场领导者地位,github上有31.8k星,如果你的团队有足够定制自研能力,想深度把控底层调度算法,也可以基于mesos做定制自研。
- 镜像治理,基于docker registry,vmware开源的harbor是目前社区比较成熟的企业级产品,在其基础上扩展了权限控制,审计,镜像同步,管理界面等治理能力,可以考虑采用。
- 资源治理,目前这块还没有生产级的开源产品,一般企业需要根据自己的场景定制自研。
- 发布平台,jenkins, Netflix开源的spinnake,但是这个产品比较复杂重量(因为它既要支持适配对接各种CI系统,同时还要适配对接各种公有云和容器云,使得整个系统异常复杂)
- IAM:是identity & access management的简称,对发布平台各个组件进行身份认证和安全访问控制
此篇文章作为学习笔记,原文章链接:https://mp.weixin.qq.com/s/ENq2UlCvF0kf0P4-fUtuxA