微服务框架
# 微服务架构介绍与框架
在互联网架构中，从原来的单一软件发展至SOA服务模式，以及现在的微服务软件架构模式，服务的独立运行。
### 微服务架构介绍
微服务架构是一种软件架构模式.将单一应用程序划分成一个个小的服务，服务之间互相调用、或者通过网关调用运行。每个服务运行在其独立的系统进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RestfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到各个软件环境等。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持业务的小服务,每个小的服务可以独立运行与部署。
切分之前
### 为什么需要微服务
在传统型应用系统中,虽然区分业务模块与基础模块,但是不能做到每个服务独立运行与部署，那么在后台将是一个统一的服务体对外提供服务，在用户访问前端使用负载均衡进行4-7的负载，后台采用缓存、数据库、共享存储进行数据的共享。
在业务代码更新过程中，不可 避免的会影响到其他业务的系统。而在上线之前，一般都会经历测试的阶段.但是在业务系统庞大之后，不论每次软件版本功能的更新大与小，测试都是无法全面测试的。有时候甚至是在当时上线没有发现问题，可能会在下次发布或者是在其他的操作过程中，才发现问题。这样处理问题的故障定位就会异常的复杂，不能快速准确的定位问题。
基于此背景，微服务概念应用而生.业务系统服务的发展经历了几个阶段:
※传统软件架构模式
※SOA (Service-Oriented Architecture,面向服务架构)模式(大概 2014年)
※微服务 (Micro Service)模式(大概2016年)
### 传统应用架构、SOA和微服务的区别
#### 传统应用架构
传统的企业级应用是单机或双机集群应用(php.tomcat). 一般采用分层结构，如应用层(代码逻辑)/数据层(数据库)，这主要是水平切分的思想。每个应用之间的耦合性比较高。
#### SOA的服务模式
SOA (面向服务的软件架构、Service Oriented Architecture).是一种软件设计模式，主要应用于不同应用组件间通过某种自定义协议来相互通信，客户端调用需要集成其SDK。
正是因为传统的软件架构模式，带来的系统每次更新与部署,都有可能会导致其他的业务模块出现异常。那么将服务拆分为独立部署的单个应用，势在必行。并且业务逻辑之间相互不影响,不需要依赖其他业务模块运行，有独立的进程与端口。
#### SOA的调用方式
在SOA软件架构模式中，通常是采用SDK(客户端软件包)的调用方式。如果有客户端需要http方式调用,那么可以在SOA软件之前添加http请求代理，这层代理通常由 php或者nginx完成。
SDK调用方式并发比http方式调用高，其主要原因是它可以采用自定义的私有协议进行通信;在自定义的协议中,对数据的传输可以做一定的优化处理。
但是SDK调用也存在一定的弊端，比如客户端调试困难客户端更新SDK版本需要考虑到兼容性。其中典型的SOA架构有:ZerocIce、Dubbo。
下图为SOA的整体调用方式:
### 微服务模式
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是移动互联网现在最流行的软件开发框架。在微服务架构中，集中式业务服务管理几乎不存在，微服务使用轻量级HTTP接口进行通信。
在SOA架构发展之后，相比Micro Service能够基于框架快速的开发应用程序,甚至都不需要专用的启动web服务(性能瓶颈)来启动微服务.而自身的软件框架已经携带。由
在各个软件运行环境中(测试、 开发、生产).运维与开发人员经常需要修改不同环境的配置文件,在操作中可能会因为失误导致服务异常的情况，经常发生.之前的SOA架构如果需要实现配置中心功能，那么需要借助第三方的配置中心(有些SOA框架自带.但是功能较弱),但是这一切相对于微服务而言.实现起来比较简单，包括一系列的服务治理(服务管理手段)方案,在框架中早已经集成，大大降低了开发人员的工作负载，使得软件开发人员只需要专注于业务逻辑开发，而不需要关心软件框架的内部实现。
### 微服务的优点与缺点
#### 微服务的优点
※优势复杂度可控(复杂度降低)
在将业务应用拆分之后，使原本复杂的应用，变得简单。每一个微服务只有单一的某一 项功能，并通过定义良好的接口调用模式，使客户端调用更加简单。由于"体积"小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
※独立部署(Web)
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。降低了应用部署的复杂度。
※技术选型灵活(SpringCloud)
微服务架构下，业务逻辑是去中心化的。每个团队可以根据自身业务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构业务也是可行的。
※容错(熔断)
当某一组建发生故障时，在单一进程管理的传统架构模式下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若代码质量高，其他服务可通过重启、销毁等机制实现应用层面的容错。
※扩展
单应用架构也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
#### 微服务的缺点
※代码重复
由于每个服务能够独立运行，有时需要向不同服务添加一些相同代码，这就会导致代码重复，并且也增加了开发人员的工作量。
※运维复杂
在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维业务系统。
※影响性能
微服务的间通过http等形式进行交互调用，通信的时延会受到较大的影响。
#### 微服务与Docker关系
Docker是一个开源应用容器(当然目前也分为CE和EE版本，不完全开源化也存在收费版本).让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到支持的操作系统(支持容器)上, 也可以使用虚拟化系统运行容器。容器是完全使用系统隔离机制.相互之间不会有任何接口依赖。
Docker只要在支持Docker的操作系统上运行.就可以运行微服务。有点类似JAVA的跨平台性,只需要JVM虚拟机就可以运行JAVA代码。
Docker作为容器工具可以把:业务逻辑容器、数据库容器、储存容器、队列容器使得软件可以拆分成若干个标准化容器，然后容器间相互通信,从而形成微服务。
#### 微服务框架
如何应对上述挑战，出现了如下微服务领域的框架：
- Spring Cloud（各个微服务基于Spring Boot实现）
- Dubbo
- Service Mesh
- Linkerd
- Envoy
- Conduit
- Istio
#### 了解Spring Cloud
[https://spring.io](https://spring.io/)
##### 核心项目及组件
https://spring.io/projects
##### Spring Boot介绍
※Spring Boot可以建立独立的Spring应用程序;
※内嵌了如Tomcat, Jetty 和Undertow这样的web容器，也就是说可以直接跑起来，用不着再做部署工作了。
##### Spring Cloud介绍
※基于Spring Boot实现的服务治理工具集.
※利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署
##### 与Dubbo对比
做一个简单的功能对比：
| 核心要素 | Dubbo | Spring Cloud |
| ------------ | ------------- | ---------------------------- |
| 服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
| …… | …… | …… |
**从上图可以看出其实Dubbo的功能只是Spring Cloud体系的一部分。**
这样对比是不够公平的，首先`Dubbo`是`SOA`时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而`Spring Cloud`诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了`Spirng`、`Spirng Boot`的优势之上，两个框架在开始目标就不一致，`Dubbo`定位服务治理、`Spirng Cloud`是一个生态。