微服务简单介绍

1. 单体架构

单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。

1.1 特点

• 一般打包成一个独立的单元，比如jar包或war包
• 以单独的进程运行

1.2 优点

• 项目易于管理
• 部署简单

1.3 缺点

• 测试成本高
• 可伸缩性差
• 可靠性差
• 迭代困难
• 跨语言程度差
• 团队协作难

2. 微服务架构

2.1 定义

微服务是一种架构风格。一般一个大型的复杂软件应用，由一个或多个微服务组成，各个微服务可被独立部署，各个微服务之间是松耦合的，每个微服务仅关注于完成一件任务并很好的完成该任务。

2.2 特点

• 系统是由多个服务构成
• 每个服务可以单独独立部署
• 服务内部高内聚，服务之间低耦合

2.3 优点

• 测试容易
• 可伸缩性强
• 可靠性强
• 跨语言程度会更加灵活
• 团队协作容易
• 系统迭代容易

2.4 缺点

• 运维成本高，部署数量较多
• 接口要兼容多版本
• 分布式系统比较复杂性
• 要实现分布式事务

3. 架构风格

微服务是一种架构风格，常见的架构风格有EJB（基于组件模型的架构）、MVC（模型-视图-控制的分层架构）、SOA（面向服务的架构）

3.1 MVC、RPC、SOA、微服务架构之间的区别

• MVC
  MVC架构其实就是一种单体架构。
  代表技术有Struts2、SpringMVC、Spring、Mybatis 等等。
• RPC
  RPC(Remote Prcedure Call)：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的服务。
  代表技术有：Thrift、Hessian 等等
• SOA
  SOA(Service oriented Architecture)：面向服务架构，主要使用ESB
  ESB(Enterparise Servce Bus)，服务总线，是一种服务中介。主要提供了一个服务与服务之间的交互。其含的功能有：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
  代表技术：Mule、WSO2
• 微服务
  微服务就是一个轻量级的服务治理方案。
  代表技术：SpringCloud、dubbo 等等

4. 微服务的设计原则

4.1 AKF拆分原则

X 轴(水平扩展) —— 按照水平扩展，也就是”加机器解决问题”
Y 轴(功能) —— 按照应用中功能划分，基于不同的业务拆分
Z 轴(数据分区) —— 按照服务和数据的优先级划分，如按地域划分

下面以一个电商平台为例来进行说明。

• X轴
  通过绝对平等地复制服务与数据，以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。
  场景：发展初期，业务复杂度低，需要增加系统容量。
  
• Y轴
  Y 轴扩展会将庞大的整体应用拆分为多个服务，每个服务实现一组相关的功能。在工程上常见的方案是服务化架构(SOA)。
  场景：业务复杂，数据量大，代码耦合度高，团队规模大。
  
• Z轴
  Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种Z 轴扩展。
  对于Z轴的扩展，有两种常用的方案：单元化架构和数据分区。
  • 单元化架构
    在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y 轴扩展的SOA 架构，客户端对服务端节点的选择一般是随机的，但是，如果在此加上Z 轴扩展，那服务节点的选择将不再是随机的了，而是每个单元自成一体。如下图：
    
  • 数据分区
    为了性能数据安全上的考虑，我们将一个完整的数据集按一定的维度划分出不同的子集，一个分区(Shard)，就是是整体数据集的一个子集。比如用尾号来划分用户，那相同尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式。
    • 数类型（如：业务类型）
    • 数据范围（如：时间段，用户ID）
    • 数据热度（如：用户活跃度，商品热度）
    • 按读写分（如：商品描述，商品库存）

4.2 无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被看做是有状态的，进而依赖这个“有状态”数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，我们是要把有状态的业务服务改变为无状态的计算类服务，从而状态数据也就相应的迁移到对应的“有状态数据服务”中，如下图所示。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，但是在微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

4.3 RestFul 的通讯风格

微服务之间的通讯应该是无状态的，为达到这个原则，推荐使用RestFul风格的通讯方式，好处有：

• 无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案HTTPS 即可；
• JSON 报文序列化，轻量简单，可读性强，学习成本低，搜索引擎友好；
• 语言无关，各大热门语言都提供成熟的Restful API 框架，相对其他的一些RPC 框架生态更完善；