微服务框架的介绍

定义：微服务框架是将某个应用程序开发划分为对许多小型服务独立的进行业务开发，这些服务一般围绕业务规则进行构建，可以用不同的语言开发，使用不同的数据存储，最终使得每个服务运行在自己的行程中。并且它们之间采用轻量级通信机制进行通信。

系统架构的演变

随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？

1. 集中式架构（ORM）

互联网刚刚诞生时，服务器成本较高，访问流量也不多，所有的程序被放到一起，然后发布到一台服务器上。

从上图可以看出，所有应用程序都被放到一起，将所有功能都部署在一起，大大减少了部署节点和成本，同时还减少了输入/输出(I/O)的操作，降低了网络通信的成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键，而这种框架被我们成为ORM框架。

存在的问题：

• 代码耦合，开发维护困难
• 无法针对不同模块进行针对性优化
• 无法水平扩展
• 单点容错率低，并发能力差

2. 垂直拆分（MVC）

当访问量逐渐增大，单一应用ORM框架已经不能满足需求，此时开发人员想到了新的方式解决，将原本的单个应用拆分成互不干扰的几个应用，以提升效率、分散流量压力：

从上图中可以看出，每个应用都是垂直的，因此，也被成为垂直应用框架。在这种情况下，通过增加机器，我们可以把曾经的单一应用系统分解成子模块，分到各个服务器上。每个子模块按照MVC框架进行分层，也就是我们常说的表现层(UI，Web层)，业务层(BLL，service层)，持久层(DAL，dao层)。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进行优化
• 方便水平扩展，负载均衡，容错率提高

缺点：

• 系统间相互独立，在应对复杂的业务场景时，开发和维护的成本增加了
• 每个应用中会出行公共功能，代码重复量提高了，不利于团队合作
• 系统的可靠性差，节点的故障会使整个系统出现雪崩效应
• 系统开发完成后，对其维护困难，在定制化时，修改代码会影响整个系统

3. 分布式服务（RPC）

在特定时期，MVC框架扮演了重要的角色，但是当垂直应用越来越多，重复的代码也原来越多，开发人员开始将核心业务抽取出来，作为一个稳定的服务中心，使前端应用能更快速的响应多变的市场需求。同时开发人员还将许多的公共应用程序接口（API）抽取出来，作为独立的公共服务给调用者调用消费，最终实现服务的共享和重用。

RPC框架可以分为三个部分：服务的提供者、消费者、注册中心，RPC通信方式的框架，屏蔽了底层的传输协议（TCP/UDP）、序列化技术(XML/JSON/ProtoBuf)和通信细节。

优点：

• 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

• 大量的服务配置，需要管理每个服务的地址，难以维护
• 服务间的依赖关系十分复杂，难以分清哪个应用要在哪个应用前启动
• 服务的调用量越来越大，服务的容量难以估计，小服务资源的浪费等问题逐渐显现

4. 流动计算架构（SOA）

SOA (Service-Oriented Architecture) 是一种粗粒度、松耦合，以服务为中心的的架构，它将应用程序的不同功能（服务）通过服务之间定义良好的接口和契约联系起来，接口之间通过定义明确的协议和接口进行通信。相对于RPC，在SOA架构中增加一个调度中心。调度中心可以基于访问压力实时管理集群容量，提高集群利用率。SOA 核心思想是服务是一种可重复的业务，将其经过标准封装达到复用的目的。

大规模系统的框架设计原则就是尽可能的拆分，以达到更好的独立扩展与伸缩、更灵活的部署、更好的隔离和容错、更高的开发效率，而其核心就是分布式。

服务治理：

• 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
• 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
• 动态监控服务状态监控报告，人为控制服务状态

缺点：

• 服务间会有依赖关系，一旦某个环节出错会影响较大
• 服务关系复杂，运维、测试部署困难，不符合DevOps思想

5. 微服务

微服务的目的就是有效的拆分应用，实现敏捷开发和部署。微服务架构和 SOA 的思想没有太大的差别，从实现的方式而言，有一些不同，微服务相比于SOA更加精细，粒度更小，服务之间耦合度更低，其更多的以独立的进程的方式存在，每个微服务都由独立的小团队负责，互相之间并无影响；微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

微服务与SOA：

方面	SOA	微服务架构
应用粒度	多个系统整合成一个服务，粒度大	一个系统拆分成多个服务，粒度小
服务架构	企业服务总线（ESB），集中式架构	服务自治，松散式架构
服务规模	服务规模较小	服务规模膨胀
服务部署	单体架构，业务耦合	功能独立，独立部署

微服务架构可以理解成 SOA 的升级版，强调实现的轻量化，做到服务粒度更细。随着敏捷开发、持续交付、虚拟化技术、DevOps 理论的实践，微服务架构越来越被重视与应用。

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
• 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。各种终端都可以调用，不关心语言、平台限制，也不关心服务的技术实现，只要提供Rest的接口即可。
• 自治：所有的微服务都能运行在自己的进程中，服务间之间互相独立，互不干扰
  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
  • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
  • 数据库分离：每个服务都使用自己的数据源
  • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

缺点：

• 可用性降低：微服务之间通过远程调用实现协作，而远程调用相对来所不稳定，需要用有效的方案来解决
• 处理分布式事务困难：当一个用户请求的业务设计多个微服务时，需要解决保障数据的一致性的问题
• 全能对象（God Classes）阻止业务拆分，每个业务都有可能存在一个或多个全能对象，比如说商城项目中的订单对象，它几乎会涉及电商应用中的每一个业务，阻止你进行业务拆分
• 学习难度大，对于开发人员的技术需求较高

微服务结构图：