Spring Cloud 自学系列（一） 微服务简介

微服务概念

微服务是一种架构模式，该概念源于Martin Fowler于2014年发表的一篇文章《Microservices》。该文章提出，把一个单独的应用程序开发为一套小服务，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是Http API或RPC。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

在笔者了解微服务概念之前，一直认为微服务和SOA类似，只是旧酒装新瓶。再做完了解后，才知道其实不然，它是一种全新的模式。

微服务的特点

• 由一系列微小的服务共同组成
• 各自跑在自己的进程里
• 每个服务为独立的业务开发
• 独立部署
• 分布式管理

什么叫单独的应用程序

传统开发中，我们会把一个单独应用程序分为三大主要部分：

• 前端：UI层，直接和用户进行交互，Web, Client, Andriod, IOS等
• 后端：数据逻辑处理层，对数据进行处理，提供给前端用于用户展示，或接收前端反馈的数据，存储进数据层。其中，后端又包含了很多业务模块，如用户模块，订单模块等。
• 数据：数据层，对数据进行固化存储，数据库，文件服务器等

应用程序最后会被放在一个容器（IIS, tomcat等)里，提供给用户进行访问。当然一个容器也不止包含一个应用程序。

单体架构的优点：

• 易测试：由于该架构不需要依赖外部组件，在本地就可以直接启动，所以容易进行测试。
• 易部署：将应用打一个包，扔进容器里，即可部署。

单体架构缺点：

• 开发效率低：虽然进行了前后端的分离，但是业务逻辑层的耦合度还是相对较高，A需要等待B功能完成，B需要等待C功能实现。而且，一群人都在一个项目内进行开发，代码间的冲突也很频繁。
• 代码维护困难：代码都在一个工程内，时间久了，该工程会变得无比巨大，导致每一次编译都需要很长时间，并且不利于新近的员工快速熟悉代码。
• 不够稳定：一个底层错误可能会导致整个应用瘫痪
• 不易扩展：虽然单体架构同样可以进行高可用集群部署，但是他不能针对某一个服务进行特殊的扩展。例如，电商应用，其商品信息模块肯定比订单模块需要的资源更多，因为浏览的用户比下单的用户更多，但是在单体应用下，他只能进行整体的横向扩展，而不能做单，只针对某一模块进行扩展。
  

一个简单的微服务架构

现在，我们在上面的基础上，将其转变为微服务的架构。

由于三层架构中，已经将前后端进行了解耦，都是通过API进行数据交互。所以，主要关注的是服务层中各服务间的解耦。

首先，是后端通用服务。我们将之前的用户模块，订单模块，商品模块拆分成一系列的子服务，并进行注册。

然后，在前端服务中，我们对已注册的后端通用服务进行组合或裁剪，组成新的服务模块。
通用服务：用户注册服务和订单查询服务
手机版服务：商品库存服务，
网页版服务：商品图片服务和商品库存服务。
由于通用服务会需要更多资源，所以我们注册了三个通用服务。

最后，服务注册，所有的服务都需要在服务注册服务中进行注册，才能进行互相通信或与客户端通信。

最最后，服务网关是连接服务端与客户端的大门。服务网关可以进行路由，可以将客户端的请求，反向路由到内部的微服务中去，并可以通过网关屏蔽后台服务的细节。

微服务优点

• 通过分解巨大单体式应用为多个服务方法解决了复杂性问题，每个微服务相对较小
• 每个单体应用不局限于固定的技术栈，开发者可以自由选择开发技术，提供API服务
• 单一职责功能，每个服务都很简单，只关注于一个业务功能
• 易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务
• 改善故障隔离。一个服务宕机不会影响其他的服务

微服务缺点

• 开发者需要应对创建分布式系统所产生的额外的复杂因素
• 部署复杂
• 内存占用量更高

微服务基础组件

• 服务网关（Service Gateway）
• 服务注册与发现
• 前端服务（Middle Tier Service）
• 后端通用服务（Edge Service）

不恰当的比喻

临时想的，让微服务架构与生活中的例子进行类比，可能不太恰当。

后端通用服务：基础食材，供应后会更新实时食材谱

前端服务：由注册的基础食材进行组合形成的菜品或套餐（中餐和西餐代表服务的实现可以为异构系统，如.net或Java）

服务注册与发现：根据食材的消耗或供给，所能产出的菜品会实时更新至实时食材谱，只有在实时食材谱中的菜品或基础食材才能进行供应。

服务网关：客户通过菜单进行点菜，客户不清楚菜品的情况，需要有服务员根据实时菜单来告诉客户有或者没有。