SpringCloud-1-微服务介绍

2.微服务概述

2.1什么是微服务

• 微服务（MicroServices）最初是由 Martin Fowler 于 2014 年发表的论文 《MicroServices》 中提出的名词
• https://martinfowler.com/articles/microservices.html
• 译文：https://www.cnblogs.com/liuning8023/p/4493156.html
• 微服务：”服务"指的是项目中的功能模块，它可以帮助用户解决某一个或一组问题，在开发过程中表现为IDEA中的一个工程或 Moudle（有独立端口的Application）；“微”强调的是单个服务的大小，微服务体积小，代码较少，复杂度低，他关注的是某一个点，只提供单个业务功能的服务，是具体解决某一个问题并且微服务团队所需成员少。

IDEA工具里面使用Maven开发的一个个独立的小Moudle,它具体是使用springboot开发的一个小模块，专业的事情交给专业的模块来做，一个模块就做着一件事情
强调的是一个个的个体，每个个体完成一个具体的任务或者功能！

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

2.2 微服务架构

• 微服务架构:一种新的架构形式，Martin Fowler,2014提出，或者说是一种架构风格，它提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值。服务之间采用轻量级的通信机制（通常是 HTTP RESTFUL API）互相沟通。
• 每个服务都围绕着具体的业务进行构建，每一个服务只专注于完成一项任务并把它做好 ，即“专业的人做专业的事”。
• 并且能够被独立的部署到到各种环境中，例如开发环境、测试环境和生产环境等，每个服务都能独立启动或销毁而不会对其他服务造成影响
• 应尽量避免统一的，集中式的服务管理机制SOA，对具体的一个服务而言，应根据业务上下文，选择合适的语言，合适的数据存储技术，工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储；

2.3 微服务架构 vs 单体架构

• 在当今的软件开发领域中，主要有两种系统架构风格，那就是新兴的“微服务架构”和传统的“单体架构”。

• 单体架构是微服务架构出现之前业界最经典的软件架构类型，许多早期的项目采用的也都是单体架构。单体架构将应用程序中所有业务逻辑都编写在同一个工程中，最终经过编译、打包，部署在一台服务器上运行。

• 在项目的初期，单体架构无论是在开发速度还是运维难度上都具有明显的优势。但随着业务复杂度的不断提高，单体架构的许多弊端也逐渐凸显出来，主要体现在以下 3 个方面：

• • 随着业务复杂度的提高，单体应用（采用单体架构的应用程序）的代码量也越来越大，导致代码的可读性、可维护性以及扩展性下降。
  • 随着用户越来越多，程序所承受的并发越来越高，而单体应用处理高并发的能力有限。
  • 单体应用将所有的业务都集中在同一个工程中，修改或增加业务都可能会对其他业务造成一定的影响，导致测试难度增加。

• 由于单体架构存在这些弊端，因此许多公司和组织都开始将将它们的项目从单体架构向微服务架构转型。对比下微服务架构和单体架构到底有什么不同。

不同点	微服务架构	单体架构
团队规模	微服务架构可以将传统模式下的单个应用拆分为多个独立的服务，每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小，团队管理成本小。	单体架构的应用程序通常需要一个大型团队，围绕一个庞大的应用程序工作，团队管理的成本大。
数据存储方式	不同的微服务可以使用不同的数据存储方式，例如有的用 Redis，有的使用 MySQL。	单一架构的所有模块共享同一个公共数据库，存储方式相对单一。
部署方式	微服务架构中每个服务都可以独立部署，也可以独立于其他服务进行扩展。如果部署得当，基于微服务的架构可以帮助企业提高应用程序的部署效率。	采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。
开发模式	在采用微服务架构的应用程序中，不同模块可以使用不同的技术或语言进行开发，开发模式更加灵活。	在采用单体架构的应用程序中，所有模块使用的技术和语言必须相同，开发模式受限。
故障隔离	在微服务架构中，故障被隔离在单个服务中，避免系统的整体崩溃。	在单体架构中，当一个组件出现故障时，故障很可能会在进程中蔓延，导致系统全局不可用。
项目结构	微服务架构将单个应用程序拆分为多个独立的小型服务，每个服务都可以独立的开发、部署和维护，每个服务都能完成一项特定的业务需求。	单体架构的应用程序，所有的业务逻辑都集中在同一个工程中。

2.4 微服务优缺点

• 优点

• 遵循单一职责原则设计模式，每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求。按照业务来划分，每个服务通常只专注于某一个特定的业务、所需代码量小，复杂度低、易于维护。
• 每个微服都可以独立开发、部署和运行，且代码量较少，因此启动和运行速度较快，并且从设计、开发、测试到维护所需的团队规模小，一般 8 到 10 人，团队管理成本小。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 在微服务架构中，开发人员可以结合项目业务及团队的特点，合理地选择语言和工具进行开发和部署，不同的微服务可以使用不同的语言和工具。
• 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins,Hudson,bamboo
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML，CSS或其他界面混合
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库
• 微服务系统具有链路追踪的能力。
• 微服务能够与容器（Docker）配合使用，实现快速迭代、快速构建、快速部署。
• 采用单体架构的应用程序只要有任何修改，就需要重新部署整个应用才能生效，而微服务则完美地解决了这一问题。在微服架构中，某个微服务修改后，只需要重新部署这个服务即可，而不需要重新部署整个应用程序。
• 微服务具备良好的可扩展性。随着业务的不断增加，微服务的体积和代码量都会急剧膨胀，此时我们可以根据业务将微服务再次进行拆分；除此之外，当用户量和并发量的增加时，我们还可以将微服务集群化部署，从而增加系统的负载能力。
• 微服务具有良好的故障隔离能力，当应用程序中的某个微服发生故障时，该故障会被隔离在当前服务中，而不会波及到其他微服务造成整个系统的瘫痪。

• 缺点：

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度，随着服务的增加，运维的压力也在增大
• 系统部署依赖
• 服务间通信成本
• 数据一致性
• 系统集成测试
• 性能监控.

2.5 微服务技术栈有哪些？

微服务条目	落地技术
服务开发	SpringBoot,Spring,SpringMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务的简化工具)	Feign等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理（github远程配置，修改）	SpringCloudConfig、Chef等
服务路由(API网关)	Zuu等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetess等（docker还不如k8s，屏蔽了语言特性）
数据流操作开发包	SpringCloud Stream(封装与Redis,Rabbit,Kafka等发送接收消息)
事件消息总线	SpringCloud Bus

2.6 微服务框架

• 微服务架构是一种系统架构风格和思想，想要真正地搭建一套微服务系统，则需要微服务框架的支持。随着微服务的流行，很多编程语言都相继推出了它们的微服务框架，下面我们就来简单列举下。
• 微服务架构4个核心问题？
• • .服务很多，客户端该怎么访问？API网关，服务路由
• • 这么多服务？服务之间如何通信？HTTP,RPC框架，异步调用
• • 这么多服务？如何治理？服务注册与发现，高可用
• • 服务挂了怎么办？重要 熔断机制，服务降级 主从备份 集群

造成这些问题的原因是：网络是不可靠的，分布式，网络丢包，数据拦截

• 解决方案：

1.spring cloud netflex 一站式解决方案。我们都可以直接去这里拿（4个问题都可解决）
  Springcloud：是一套生态，就是来解决以上分布式架构的4个问题,以http restful风格进行通信的框架。想使用springcloud,必须要掌握SpringBoot,因为SpringCloud是基于SpringBoot;
	Api网关，zuul组件
	Feign-->Httpclient--->HTTP的通信方式（超文本传输协议，负载均衡），同步并阻塞
	服务注册与发现，Eureka
	熔断机制，Hystrix

2.Apache Dubbo zookeeper半自动，需要整合别人的！
	API Gateway:没有！要么找第三方组件，要么自己实现网关
	Dubbo是一个高性能的基于Java实现的RPC通信框架（异步非阻塞）！2.6.x
	服务注册与发现，zookeeper（大数据用的多）:动物园管理者(Hadoop,Hive)
	没有：借助了Hystrix
	
	不完善，专一做rpc通信框架，不和spring cloud竞争
	
3.SpringCloud Alibaba一站式解决方案！相对netflex简单
	Spring Cloud Gateway
	Dubbo是一个高性能的基于Java实现的RPc通信框架（异步非阻塞）！2.6.x
	Nacos：动态服务发现、配置和服务管理平台
	Sentinel： 以流量为切入点，从流量控制、熔断降级、系统负载保护、

Java 微服务框架

市面上的 Java 微服务框架主要有以下 5 种：

• Spring Cloud：它能够基于 REST 服务来构建服务，帮助架构师构建出一套完整的微服务技术生态链。
• Dropwizard：用于开发高性能和 Restful 的 Web 服务，对配置、应用程序指标、日志记录和操作工具都提供了开箱即用的支持。
• Restlet： 该框架遵循 RST 架构风格，可以帮助 Java 开发人员构建微服务。
• Spark：最好的 Java 微服务框架之一，该框架支持通过 Java 8 和 Kotlin 创建微服务架构的应用程序。
• Dubbo：由阿里巴巴开源的分布式服务治理框架。

Go 语言微服务框

Go 语言中的微服务框架较少，使用的较多的是 GoMicro，它是一个 RPC 框架，具有负载均衡、服务发现、同步通信、异步通讯和消息编码等功能。

Phyton 微服务框架

Phyton 中的微服务框架主要有 Flask、Falcon、Bottle、Nameko 和 CherryPy 等。

NodeJS微服务框架

Molecular 是一种使用 NodeJS 构建的事件驱动架构，该框架内置了服务注册表、动态服务发现、负载均衡、容错功能和内置缓存等组件。

为什么选择SpringCloud作为微服务架构?

• 选型依据

整体解决方案和框架成熟度
社区热度
可维护性

学习曲线:注解

• 当前各大T公司用的微服务架构有哪些？

阿里：dubbo+HFS

京东：JSF
新浪：Motan
当当网DubboX

2.7 各微服务框架对比

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	整套微服务框架	RPC框架，整合了ZK或consul实现集群环境的基本服务注册、发现	RPC框架	RPC框架	服务框架
支持rest	是，Ribbon支持多种可拔插序列号选择	否	否	否	否
支持RPC	否	是（hession2）	是	是	是
支持多语言	是（rest形式？）	否	是	是	是
负载均衡	是（服务端zuul+客户端Ribbon）zuul-服务，动态路由，云端负载均衡Eureka（针对中间服务层）	是（客户端）	否	否	是（客户端）
配置服务	Netflix Archaius，Spring Cloud Config Service集中配置	是（zookeeper提供）	否	否	否
服务调用链监控（路由网关）	是（zuul）zuul提供边缘服务，API网关	否	否	否	否
高可用、容错	是（服务端Hystrix）+客户端Ribbon	是（客户端）	否	否	是（客户端）
应用案例	Netflix	Sina	Google	Facebook
社区活跃度	高	一般	高	一般	17重新维护，之前中断5年
学习难度	高	低	高	高	低
文档丰富	高	一般	一般	一般	高
其他	SpringCloud Bus给我们的应用程序带来更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践公司多

下一篇：SpringCloud-2-入门概述