什么是微服务架构

转载于https://www.toudo.cn/article/13

互联网应用架构历程

随着互联网的发展，用户群体逐渐扩大，网站的流量成倍增长，常规的单体架构已无法满足请求压力和业务的快速迭代，架构势在必行。下面以某网的架构演示为例，从最开始的单体架构分析，一步步的到现在的微服务架构。

单机应用架构

网站诞生之初，因为用户量、数据量规模都很小，项目的所有功能模块都放在一个工程中编码、编译、打包并部署在一个Tomcat容器中的架构模式就是单体应用架构，这样的架构既简单实用、便于维护，成本又低，成为了那个时代的主流架构方式。

优点：

• 项目前期开发节奏块，项目成员少的时候能快速迭代。
• 架构简单，MVC架构，只需要借助IDE开发、调试即可。
• 易于测试：只需要通过单元测试或者浏览器即可完成。
• 易于部署：打成jar包或者war包放到容易内启动。
  缺点：
• 随着不断的功能迭代，单个项目过大，代码杂乱，耦合严重，开发团队逐渐壮大以后，沟通成本变高，如：代码从编译到启动耗时3-5分钟甚至更长。
• 新增业务困难：在已经杂乱如麻的系统中增加新业务，维护旧功能，一脚踩进去全是不可预测的问题。新人来了以后很难接手任务，学习成本高，需要大概一周的时间才能上手工作。
• 核心业务与边缘业务混合在一起，出现问题相互影响，如：一个临时活动流量猛涨，机器负载升高就会影响正常的业务服务。

业务量上涨以后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上手段来增强应对 高并发的能力、应对一定的复杂业务场景，不过依然属于单体架构。

单体架构进一步扩展

垂直应用架构

为了避免上面提到的问题，开始做模块的垂直划分，做垂直划分的原则是基于现有的业务特性来做，核心目标第一是为了业务之间互不影响，第二是在研发团队扩大后为了提高效率，减少之间的依赖。

优点：

• 系统拆分实现了流量分担，解决了并发问题。
• 可以针对不同模块进行优化。
• 方便水平扩展，负载均衡，容错率提高
• 系统间相互独立，互不影响，新的业务迭代时更加高效。
  缺点：
• 服务之间相互调用，如果某个服务的ip或者端口发生改变，调用的系统需要手动改变。
• 搭建集群之后，实现负载均衡比较复杂，比如：内网负载，在迁移机器时会影响调用方的路由，导致线上故障。
• 服务之间调用方式不统一，基于httpClient、webservice，接口协议不统一。
• 服务监控不到位，除了依靠端口、进程的监控，调用的成功率、失败率、总耗时等等这些监控 指示标是没有用的。

SOA应用架构

在做了垂直划分以后，模块随之增多，维护的成本也在变高，一些通用的业务和模块重复的越来越多，为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡，引入了阿里巴巴开源的Dubbo，一款高性能、轻量级的开源Java RPC框架，他提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
SOA (Service-Oriented Architecture)，即面向服务的架构。根据实际业务把系统拆分成合适的、独立部署的模块、模块之间相互独立（通过webservice/Dubbo等通信技术）。

优点：分布式、松耦合、扩展灵活、可重用。
缺点：服务抽取粒度较大、服务调用方和接口提供方耦合度较高。（接口耦合度）

微服务应用架构

微服务架构可以说是SOA架构的一种扩展，这种架构模式下他的拆分粒度更小，服务更独立。把应用拆分成一个个微小的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微小、独立、轻量级通信。
微服务是在SOA上做的升华粒度更加细致，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”。

微服务架构体现的思想以及优缺点

微服务架构设计的核心思想就是”微“，拆分的粒度相对比较小，这样的话单一职责、开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强，升级改造影响范围小。
微服务架构的优点：

• 微服务很小，便于特定业务功能的聚焦A、B、C、D
• 微服务很小，每个微服务都可以被一个小团队单独实施（开发、测试、部署、运维），团队合作一定程度上解耦，便于实施敏捷开发
• 微服务很小， 便于重用和模块之间的组装
• 微服务很独立，不同的模块之间可以使用不同的开发语言，松耦合
• 微服务架构下，我们更容易引入新技术
• 微服务架构下，我们可以更好的实现Devops开发运维一体化。
  微服务架构的缺点：
• 微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂
• 微服务架构下，分布式链路追踪难等。

微服务架构中的一些概念

服务注册与发现

服务注册：服务提供者将所提供服务的信息（服务器ip和端口、协议）注册/登记到注册中心。
服务发现：服务消费者能够从注册中心获取到较为实时的服务列表，然后根据一定的策略选择一个服务访问。

负载均衡

负载均衡即将请求压力分发到多个服务器（应用服务器、数据库服务器等），以此来提高服务的性能、可靠性。

熔断

熔断即断路保护。微服务架构中，如果下游服务因访问压力过大而响应变慢或者失败，上游服务为了保护系统整体可用性，可以暂时切断对下游服务的调用。这种牺牲局部保全整体的措施叫做熔断。

链路追踪

微服务架构越发流行，一个项目往往拆分成很多个服务，那么一次请求就需要涉及到很多个服务。不同的微服务可能是由不同的开发团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在了很多服务器上（甚至百台、千台）横跨多个不同的数据中心。所谓链路追踪，就是对一次请求涉及的很多个服务链路进行日志记录、性能监控。

API网关

微服务架构下，不同的微服务往往会有不同的访问地址，客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

1. 客户端需要调用不同的url地址，增加了维护调用难度。
2. 在一定的场景下，也会存在跨域请求的问题（前后端分离就会遇到跨域的问题，原本我们在后端采用Cors就能解决，现在利用网关，那么就放在网关这层做好了）
   3.每个微服务都需要进行单独的身份认证
   那么API网关就能较好的统一处理上述问题，API请求调用统一接入API网关层，由网关转发请求。API网关更专注在安全、路由、流量等问题的处理上（微服务团队专注于处理业务逻辑即可）它的功能比如

• 统一接入路由
• 安全防护（统一鉴权，负责网关访问身份认证验证，与“访问认证中心”通信，实际认证业务逻辑交移“访问认证中心”处理）
• 黑白名单（实现通过ip地址控制禁止访问网关功能，控制访问）
• 协议适配（实现通信协议校验、适配转换的功能）
• 流量管控（限流）
• 长短链接支持
• 容错能力（负载均衡）