微服务概述

SpringCloud 2018

GitHub



1-微服务概述

1.1-面试题

  • 什么是微服务?

  • 微服务之间是如何独立通讯的?

  • SpringCloud 和 Dubbo 有哪些区别?

  • SpringBoot 和 SpringCloud,请你谈谈对他们的理解?

  • 什么是服务熔断?什么是服务降级?

  • 微服务的优缺点分别是什么?说下你在项目开发中碰到的坑?

  • 你所知道的微服务技术栈有哪些?请列举一二?

  • Eureka 和 Zookeeper 都可以提供服务注册与发现的功能,请说说两个的区别?

1.2-是什么

业界大牛马丁.福勒(Martin Fowler)论文网址(https://martinfowler.com/articles/microservices.html)

就目前而言,对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architectural style)

通常而言,微服务架构是一种架构模式或者说是一种架构风格:它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于 Http 的 Restful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。

技术维度理解:微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事。 从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立的数据库

1.3-微服务拆分

微服务无统一维度主要原因:拆分维度的界定

从单体式结构转向微服务架构中会持续碰到服务边界划分的问题:比如 我们有 User 服务来提供用户的基础信息,那么用户的头像和图片等是应该单独划分为一个新的 Service 更好还是应该合并到 User 服务里呢?如果服务的粒度划分的过粗,那就回到了单体式的老路;如果过细,那服务间调用的开销就变得不可忽视了,管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准,只能根据不同的业务系统加以调节。

拆分的大原则是当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过 2 个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块。

1.4-微服务设计

  • 单一职责原则

    每个微服务只需要实现自己的业务逻辑就可以了,比如订单管理模块,它只需要处理订单的业务逻辑就可以了,其它的不必考虑。

  • 服务自治原则

    每个微服务从开发、测试、运维等都是独立的,包括存储的数据库也都是独立的,自己就有一套完整的流程,我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

  • 轻量级通信原则

    首先是通信的语言非常的轻量,其次该通信方式需要是跨语言、跨平台的,之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性,可以不受技术的钳制。

  • 接口明确原则

    由于微服务之间可能存在着调用关系,为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整,在设计之初就要考虑到所有情况,让接口尽量做的更通用,更灵活,从而尽量避免其它模块也做调整。


2-微服务与微服务架构

2.1-微服务

微服务强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用。狭意的看:可以看作 Eclipse 里面的一个个微服务工程或者 Module。

2.2-微服务架构

微服务架构是⼀种架构模式,它提倡将单⼀应⽤程序划分成⼀组小的服务,服务之间互相协调、互相配合,为⽤户提供最终价值。每个服务运⾏在其独立的进程中,服务与服务间采⽤轻量级的通信机制互相协作(通常是基于 Http 协议的 Restful API)。每个服务都围绕着具体业务进⾏构建,并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外应当尽量避免统⼀的、集中式的服务管理机制,对具体的⼀个服务⽽⾔,应根据业务上下⽂,选择合适的语⾔、⼯具对其进⾏构建。


3-微服务优缺点

3.1-微服务优点

  • 每个服务足够内聚,足够小,代码容易理解这样能聚焦一个指定的业务功能或业务需求。

  • 开发简单、开发效率提高,一个服务可能就是专一的只干一件事。

  • 微服务能够被小团队单独开发,这个小团队是 2 ~ 5 人的开发人员组成。

  • 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。

  • 微服务能使用不同的语言开发。

  • 易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如 Jenkins、Hudson、Bamboo。

  • 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

  • 微服务允许你利用融合最新技术。

  • 微服务只是业务逻辑的代码,不会和 Html、Css 或其他界面组件混合。

  • 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一数据库。

3.2-微服务缺点

  • 开发人员要处理分布式系统的复杂性。

  • 服务运维难度,随着服务的增加,运维的压力也在增大。

  • 系统部署依赖。

  • 服务间通信成本。

  • 数据一致性。

  • 系统集成测试。

  • 性能监控。


4-微服务技术栈

4.1-技术栈

微服务条目落地技术
服务开发Spring Boot、Spring、SpringMVC 等。
服务配置与管理Netflix 公司的 Archaius、阿里的 Diamond 等。
服务注册与发现Eureka、Consul、Zookeeper 等。
服务调用Rest、RPC、gRPC。
服务熔断器Hystrix、Envoy 等。
负载均衡Ribbon、Nginx 等。
服务接口调用(客户端调用服务简化工具)Feign 等。
消息队列Kafka、RabbitMQ、ActiveMQ 等。
服务配置中心管理Spring Cloud Config、Chef 等。
服务路由(API网关)Zuul 等。
服务监控Zabbix、Nagios、Metrics、Spectator 等。
全链路追踪Zipkin,Brave、Dapper 等。
服务部署Docker、OpenStack、Kubernetes 等。
数据流操作开发包SpringCloud Stream(封装与Redis、Rabbit、Kafka等发送接收消息)。
事件消息总线SpringCloud Bus。

4.1-技术选型

a、选型依据

  • 整体解决方案和框架成熟度。

  • 社区热度。

  • 可维护性。

  • 学习曲线。

b、大公司的微服务架构

  • 阿里 Dubbo、HSF。
  • 京东 JSF。
  • 新浪微博 Motan。
  • 当当网 DubboX。

c、微服务框架对比
在这里插入图片描述


已标记关键词 清除标记
限时福利1:原价 129 元,最后2天仅需 69 元!后天涨价至98元 限时福利2:购课进答疑群专享柳峰(刘运强)老师答疑服务 限时福利3:购课添加助教领取价值 800 元的编程大礼包 为什么需要掌握高性能的MySQL实战? 由于互联网产品用户量大、高并发请求场景多,因此对MySQL的性能、可用性、扩展性都提出了很高的要求。使用MySQL解决大量数据以及高并发请求已经是程序员的必备技能,也是衡量一个程序员能力和薪资的标准之一。 为了让大家快速系统了解高性能MySQL核心知识全貌,我为你总结了「高性能 MySQL 知识框架图」,帮你梳理学习重点,建议收藏! 【课程设计】 课程分为四大篇章,将为你建立完整的 MySQL 知识体系,同时将重点讲解 MySQL 底层运行原理、数据库的性能调优、高并发、海量业务处理、面试解析等。 一、性能优化篇: 主要包括经典 MySQL 问题剖析、索引底层原理和事务与锁机制。通过深入理解 MySQL 的索引结构 B+Tree ,学员能够从根本上弄懂为什么有些 SQL 走索引、有些不走索引,从而彻底掌握索引的使用和优化技巧,能够避开很多实战中遇到的“坑”。 二、MySQL 8.0新特性篇: 主要包括窗口函数和通用表表达式。企业中的许多报表统计需求,如果不采用窗口函数,用普通的 SQL 语句是很难实现的。 三、高性能架构篇: 主要包括主从复制和读写分离。在企业的生产环境中,很少采用单台MySQL节点的情况,因为一旦单个节点发生故障,整个系统都不可用,后果往往不堪设想,因此掌握高可用架构的实现是非常有必要的。 四、面试篇: 程序员获得工作的第一步,就是高效的准备面试,面试篇主要从知识点回顾总结的角度出发,结合程序员面试高频MySQL问题精讲精练,帮助程序员吊打面试官,获得心仪的工作机会。
©️2020 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页