微服务写的最全的一篇文章

今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。

 

1.什么是微服务

1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可)

2)独立的进程(java的tomcat,nodejs等)

3)轻量级的通信(不是soap,是http协议)

4)基于业务能力(类似用户服务,商品服务等等)

5)独立部署(迭代速度快)

6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择)

ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。

2. 怎么权衡微服务的利于弊

利:

强模块边界 。(模块化的演化过程:类-->组件/类库(sdk)-->服务(service),方式越来越灵活)

可独立部署。

技术多样性。

弊:

分布式复杂性。

最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题)

运维复杂性。

测试复杂性。

3. 企业在什么时候考虑引入微服务

从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的时候,业务简单,用单体服务反而生产力很高。随着公司的发展,业务复杂性慢慢提高,这时候就可以采用微服务来提升生产力了。至于这个转化的点,需要团队的架构师来进行各方面衡量,就个人经验而言,团队发展到百人以上,采用微服务就很有必要了。

有些架构师是具有微服务架构能力,所以设计系统时就直接设计成了微服务,而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法,因为一开始对业务领域并不是很了解,并且业务模式还没有得到验证,这时候上微服务风险比较高,很有可能失败。所以建议大家在单服务的应用成熟时,并且对业务领域比较熟悉的时候,如果发现单服务无法适应业务发展时,再考虑微服务的设计和架构。

4.微服务的组织架构

如上图左边,传统的企业中,团队是按职能划分的。开发一个项目时,会从不同的职能团队找人进行开发,开发完成后,再各自回到自己的职能团队,这种模式实践证明,效率还是比较低的。

如上图右边,围绕每个业务线或产品,按服务划分团队。团队成员从架构到运维,形成一个完整的闭环。一直围绕在产品周围,进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模,建议按照亚马逊的两个披萨原则,大概10人左右比较好。

5:怎么理解中台战略和微服务

中台战略的由来:马云2015年去欧洲的一家公司supersell参观,发现这个公司的创新能力非常强,团队的规模很小,但是开发效率很高。他们就是采用中台战略。马云感触很深,回国后就在集团内部推出了中台战略。

简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台,把前端的应用变得更小更灵活。当中台越强大,能力就越强,越能更好的快速响应前台的业务需求。打个比喻,就是土壤越肥沃,越适合生长不同的生物,打造好的生态系统。

6:服务分层

每个公司的服务分层都不相同,有的公司服务没有分层,有的怎分层很多。目前业界没有统一的标准。

下面推荐一个比较容易理解的两层结构。

1:基础服务: 比如一个电商网站,商品服务和订单服务就属于基础服务(核心领域服务)。缓存服务,监控服务,消息队列等也属于基础服务(公共服务)

2:聚合服务 :例如网关服务就算一种聚合服务(适配服务)。

这是一种逻辑划分,不是物理划分,实际设计的东西很多很复杂。

7:微服务的技术架构体系

下图是一个成型的互联网微服务的架构体系:

1:接入层 负载均衡作用,运维团队负责

2:网关层 反向路由,安全验证,限流等

3:业务服务层 基础服务和领域服务

4:支撑服务层

5:平台服务

6:基础设施层 运维团队负责。(或者阿里云)

8:微服务的服务发现的三种方式

第一种:如下图所示,传统的服务发现(大部分公司的做法)。服务上线后,通知运维,申请域名,配置路由。调用方通过dns域名解析,经过负载均衡路由,进行服务访问。缺点: LB的单点风险,服务穿透LB,性能也不是太好

第二种:也叫客户端发现方式。如下图所示。通过服务注册的方式,服务提供者先注册服务。消费者通过注册中心获取相应服务。

并且把LB的功能移动到了消费者的进程内,消费者根据自身路由去获取相应服务。优点是,没有了LB单点问题,也没有了LB的中间一跳,性能也比较好。但是这种方式有一个非常明显的缺点就是具有非常强的耦合性。针对不同的语言,每个服务的客户端都得实现一套服务发现的功能。

第三种:也叫服务端发现方式,如下图所示。和第二种很相似。但是LB功能独立进程单独部署,所以解决了客户端多语言开发的问题。唯一的缺点就是运维成比较高,每个节点都得部署一个LB的代理,例如nginx。

9.微服务网关

网关就好比一个公司的门卫。屏蔽内部细节,统一对外服务接口。

下图是一个网关所处位置的示例图。

10:Netflix Zuul网关介绍

核心就是一个servlet,通过filter机制实现的。主要分为三类过滤器:前置过滤器,过滤器和后置过滤器。

主要特色是,这些过滤器可以动态插拔,就是如果需要增加减少过滤器,可以不用重启,直接生效。原理就是:通过一个db维护过滤器(上图蓝色部分),如果增加过滤器,就将新过滤器编译完成后push到db中,有线程会定期扫描db,发现新的过滤器后,会上传到网关的相应文件目录下,并通知过滤器loader进行加载相应的过滤器。

整个网关调用的流程

上图从左变http Request开始经过三类过滤器,最终到最右边的Http Response,这就是Zull网关的整个调用流程。

11:微服务的路由发现体系

整个微服务的路由发现体系,一般由服务注册中心和网关两部分组成。以NetFlix为例子,Eureka和Zull这两个组件支撑了netFlix整个的路由发现体系。如下图所示,首先外部请求发送到网关,网关去服务注册中心获取相应的服务,进行调用。其次内部服务间的调用,也通过服务注册中心进行的

12.微服务配置中心

目前大部分公司都是把配置写到配置文件中,遇到修改配置的情况,成本很高。并且没有修改配置的记录,出问题很难追溯。配置中心就接解决了以上的问题。

可配置内容:数据库连接,业务参数等等

配置中心就是一个web服务,配置人员通过后台页面修改配置,各个服务就会得到新的配置参数。实现方式主要有两种,一种是push,另一种是pull。两张方式各有优缺点。push实时性较好,但是遇到网络抖动,会丢失消息。pull不会丢失消息但是实时性差一些。大家可以同时两种方式使用,实现一个比较好的效果。如下图所示,这是一个国内知名互联网公司的配置中心架构图。

开源地址:http://github.com/ctripcorp/appollo

13:RPC遇到了REST

内部一些核心服务,性能要求比较高的可以采用RPC,对外服务的一般可以采用rest。

14:服务框架和治理

微服务很多的时候,就需要有治理了。一个好的微服务框架一般分为以下14个部分。如下图所示。这就是开篇所说的,微服务涉及的东西很多,有些初创公司和业务不成熟的产品是不太适合的,成本比较高。

目前国内比较好的微服务框架就是阿里巴巴的DUBBO了,国外的就是spring cloud,大家可以去研究一下.

15:监控体系

监控是微服务治理的重要环节。一般分为以下四层。如下图所示。

监控的内容分为五个部分:日志监控,Metrics监控(服务调用情况),调用链监控,告警系统和健康检查。

日志监控,国内常用的就是ELK+KAFKA来实现。健康检查和Metrics,像spring boot会自带。Nagios也是一个很好的开源监控框架。

16:Trace调用链监控

调用链监控是用来追踪微服务之前依赖的路径和问题定位。例如阿里的鹰眼系统。主要原理就是子节点会记录父节点的id信息。

下图是目前比较流行的调用链监控框架。

17:微服务的限流熔断

假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务,继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高,则会导致调用A服务的请求被堵住,堵住的请求会消耗占用掉系统的线程、io等资源,当该类请求越来越多,占用的计算机资源越来越多的时候,会导致系统瓶颈出现,造成其他的请求同样不可用,最终导致业务系统崩溃。

一般情况对于服务依赖的保护主要有两种方式:熔断和限流。目前最流行的就是Hystrix的熔断框架。

下图是Hystrix的断路器原理图:

限流方式可以采用zuul的API限流方法。

18.Docker 容器部署技术&持续交付流水线

随着微服务的流行,容器技术也相应的被大家重视起来。容器技术主要解决了以下两个问题:

1:环境一致性问题。例如java的jar/war包部署会依赖于环境的问题(操着系统的版本,jdk版本问题)。

2:镜像部署问题。例如java,rubby,nodejs等等的发布系统是不一样的,每个环境都得很麻烦的部署一遍,采用docker镜像,就屏蔽了这类问题。

下图是Docker容器部署的一个完整过程。

更重要的是,拥有如此多服务的集群环境迁移、复制也非常轻松,只需选择好各服务对应的Docker服务镜像、配置好相互之间访问地址就能很快搭建出一份完全一样的新集群。

19.容器调度和发布体系

目前基于容器的调度平台有Kubernetes,mesos,omega。下图是mesos的一个简单架构示意图。

下图是一个完整的容器发布体系

--------------------- 本文来自 yunzhaji3762 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/yunzhaji3762/article/details/82860256?utm_source=copy 

1、课程简介 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。        在本套课程中,我们将全面的讲解Spring Cloud技术栈, 从环境的部署到技术的应用,再到项目实战,让我们不仅是学习框架技术的使用,而且可以学习到使用Spring Cloud如何解决实际的问题。 Spring Cloud各个组件相互配合,合作支持了一套完整的服务架构。 - 注册中心负责服务的注册与发现,很好将各服务连接起来 - 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。 - API网关负责转发所有对外的请求和服务 - 配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息 - 链路追踪技术可以将所有的请求数据记录下来,方便我们进行后续分析 - 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况 2、适应人群 有一定的Java基础,并且要有一定的web开发基础。 3、课程亮点        系统的学习Spring Cloud技术栈,由浅入深的讲解服务技术。涵盖了基础知识,原理剖析,组件使用,源码分析,优劣分析,替换方案等,以案例的形式讲解服务中的种种问题和解决方案 l  服务的基础知识 n  软件架构的发展史 n  服务的核心知识(CAP,RPC等) l  注册中心 n  Eureka搭建配置服务注册 n  Eureka服务端高可用集群 n  Eureka的原理和源码导读 n  Eureka替换方案Consul n  Consul下载安装&服务注册&高可用 l  服务发现与服务调用 n  Ribbon负载均衡基本使用&源码分析 n  Feign的使用与源码分析 n  Hystrix熔断(雪崩效应,Hystrix使用与原理分析) n  Hystrix替换方案Sentinel l  服务网关 n  Zuul网关使用&原理分析&源码分析 n  Zuul 1.x 版本的不足与替换方案 n  SpringCloud Gateway深入剖析 l  链路追踪 n  链路追踪的基础知识 n  Sleuth的介绍与使用 n  Sleuth与Zipkin的整合开发 l  配置中心 n  SpringClond Config与bus 开发配置中心 n  开源配置中心Apollo 4、主讲内容 章节一: 1.     服务基础知识 2.     SpringCloud概述 3.     服务注册中心Eureka 4.     Eureka的替换方案Consul 章节二: 1.     Ribbon实现客户端负载均衡 2.     基于Feign的服务调用 3.     服务熔断技术Hystrix 4.     Hystrix的替换方案Sentinel 章节三: 1.     服务网关Zuul的基本使用 2.     Zuul1.x 版本的不足和替换方案 3.     深入SpringCloud Gateway 4.     链路追踪Sleuth与Zipkin 章节四: 1.     SpringCloud Config的使用 2.     SpringCloud Config结合SpringCloud Bus完成动态配置更新 3.     开源配置中心Apollo
[为什么要学习Spring Cloud服务] SpringCloud作为主流服务框架,已成为各互联网公司的首选框架,国内外企业占有率持续攀升,是Java工程师的必备技能。就连大名鼎鼎的阿里巴巴dubbo也正式更名为Spring Cloud Alibaba,成为了Spring Cloud 服务中的一个子模块。Spring Cloud是企业架构转型、个人能力提升、架构师进阶的不二选择。 【推荐你学习这门课的理由】 1、本课程总计29课时,从服务是什么、能够做什么开始讲起,绝对的零基础入门 2、课程附带全部26个项目源码,230页高清PDF正版课件 【课程知识梳理】 1、先讲解了什么是单体架构、什么是服务架构、他们之间有什么区别和联系,各自有什么优缺点。 2、从本质入手,使用最简单的Spring Boot搭建服务,让你认清服务是一种思想和解决问题的手段,而不是新兴技术。 3、讲解Spring Boot 与Spring Cloud 服务架构之间的联系,原生的RestTemplate工具,以及Actuator监控端点的使用。 4、带着服务所带来的各种优缺点,为大家引入服务发现与注册的概念和原理,从而引入我们的第一个注册中心服务Eureka。 5、引入负载均衡的理念,区分什么是服务端负载均衡,什么是客户端负载均衡,进而引入Ribbon负载均衡组件的详细使用。 6、为了解决服务之间复杂的调用,降低代码的复杂度,我们引入了Feign声明式客户端,让你几行代码搞定服务的远程调用。 7、最后为大家介绍了整个服务体系应该包含什么,学习路线是什么,应该学习什么。 【学习方法】 每一节课程均有代码,最好的方式是静下心来,用一天的时间,或者两个半天时间来学习。 一边听我的讲解,一边使用我提供的项目代码进行观察和运行。 只要你能跟住我的节奏,你就可以搞定服务
本课程总计13大章节,115课时,是一门全面的SpringCloud服务体系化课程。课程共包括十三个大章节,涵盖注册中心、网关、熔断、降级、监控、安全、限流等全部体系。包含阿里巴巴Nacos,Consul,Spring Cloud Gateway,OAuth2.0 JWT 等主流技术。 [为什么要学习Spring Cloud服务] SpringCloud作为主流服务框架,已成为各互联网公司的首选框架,国内外企业占有率持续攀升,是Java工程师的必备技能。就连大名鼎鼎的阿里巴巴dubbo也正式更名为Spring Cloud Alibaba,成为了Spring Cloud 服务中的一个子模块。Spring Cloud是企业架构转型、个人能力提升、架构师进阶的不二选择。   【推荐你学习这门课的理由:知识体系完整+丰富学习资料】 1、本课程总计13大章节,115课时,是一门全面的SpringCloud服务体系化课程。 2、课程0基础入门,逐层递进深入,理论和代码相结合。 3、十三个大章节,涵盖注册中心、网关、熔断、降级、监控、安全、限流等全部体系。 4、包含阿里巴巴Nacos,Consul,Spring Cloud Gateway,OAuth2.0 JWT 主流技术。 5、课程附带230页高清PDF正版课件、Hoxton版本配套项目源码37个、Edgware版本配套项目26个,所有代码均有详细注释。 【主讲讲师】 尹洪亮Kevin: 现任职某互联网公司首席架构师,负责系统架构、项目群管理、产品研发工作。 10余年软件行业经验,具有数百个线上项目实战经验。 擅长JAVA技术栈、高并发高可用伸缩式服务架构、DevOps。 主导研发的蜂巢服务架构已经成功支撑数百个服务稳定运行 【学完后我将达到什么水平?】 1、 对Spring Cloud的各个组件能够熟练配置、开发、部署。 2、 吊打一切关于Spring Cloud服务的笔试面试题 3、 能够上手搭建十分完整的服务分布式系统,涵盖服务注册与发现、负载、网关、配置中心、监控、安全、熔断等。 4、 对整个服务体系架构有十分清晰准确的掌握。 【面向人群】 1、 不了解服务是什么,感觉服务很难、不敢学,网上资料松散,没有好的学习资料 2、 这么多年还一直在SSH、SSM项目,没有更新过自己的知识体系。 3、 Spring Cloud组件太多,不知道应该重点关注和学习哪些。 4、 不会搭建服务项目、依赖项目太多、完全搞不清楚。 【课程知识体系图】
©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页