• 一、业务介绍
• 二、基于单体架构的打车应用
• 三、因此微服务架构被提出，用来解决这些问题
• 四、微服务架构的优缺点
• 五、微服务架构与单体架构的适用性
• 六 微服务架构设计原则——高内聚、松耦合
• Uber打车应用
• 考虑空气污染的道路收费系统

为了更形象的理解微服务架构，这里会以云视频监控告警应用为案例，详细介绍其单体架构是什么样，微服务架构是什么样，进而解释单体架构的缺点，以及微服务架构的定义，特征，以及优势。最后将单体架构与微服务架构的适用情况进行对比，解释两者的权衡。

一、业务介绍

此业务参考亚马逊[Create a Serverless Solution for Video Frame Analysis and Alerting

AWS Machine Learning Blog (amazon.com)](https://aws.amazon.com/cn/blogs/machine-learning/create-a-serverless-solution-for-video-frame-analysis-and-alerting/)

当有人出现在特定区域时中时向用户发送告警信息，比如仓库鱼塘等地方的安全监控应用。其业务流程为

1. 摄像头监视特定区域，通过因特网将视频帧发送到云端。
2. 云端接收视频帧进行存储并目标检测，
3. 若目标检测出区域内有人，则发送告警信息给用户
4. 用户可通过云端存储随时查看监控视频

二、基于单体架构的打车应用

就这样一个应用场景，如果将其做成单体架构的话会是怎么样的

首先，单体架构的定义：系统中主要的过程调用都是进程内调用，不会发生进程间通信。也就是说所有业务逻辑的代码写完后封装到一个程序里面运行。就想下图所示，可以是模块化的代码书写，但是每个模块都会整合成一个可执行程序来运行。跟我们平时写仿真是一样的，可以是多个代码文件，但其实只需要run一次就能运行整个程序。

因此，如果将上述应用做成单体架构，就是右图所示。

优点：

• 开发简单，功能都在单个程序内部，就比如我们写仿真，就在一个文件夹里就能写全部的代码。
• 容易部署测试，只需要一个安装包。只需要点一个run, 就能让整个系统运行起来。

缺点：

• 可靠性差，一行代码出问题，整个系统将瘫痪，就比如，目标识别的代码除了问题，会导致存储的视频页查看不了了。
• 难以扩展，扩展是值得当用户规模增长时，怎么让应用程序匹配需求，就比如摄像头数目增多，那么就需要部署更多服务器进行存储，但是可能目标识别的压力并不是很大，并不需要扩展。但是这种单体架构是部署整个应用，当扩展时需要满足存储和计算需求，导致一定的资源浪费，比如目标识别需要GPU，视频存储需要硬盘，当扩展应用时，需要满足所有条件。
• 当系统业务增多时，过于复杂，不仅要目标识别，需要增加其他业务，比如说识别出来人员信息，是什么动物这种需求，导致代码量剧增，维护这一个软件就需要几万行代码，错一行整个系统就会出问题。

三、因此微服务架构被提出，用来解决这些问题

首先就是微服务架构的定义：一种架构风格，将单体应⽤划分成一组小的服务，服务之间相互协作，实现业务功能 ； 每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（通常是HTTP/ JSON）；每个服务围绕业务能力进行构建，并且能够通过自动化机制独⽴地部署 ；无集中式管理，每个服务可以使用不同的语言开发，使⽤用不同的存储技术。

• 一组小的服务
• 独立的进程，跟单体架构相对，独立的进程会让服务之间没有干扰，比如爆内存了，不会影响其他服务
• 轻量级的通信机制，轻量级指的是服务间操作比较简单，比如增删改查这四种简单操作。
• 围绕业务能力，
• 独⽴地部署，
• 无集中式管理

四、微服务架构的优缺点

优点：

• 可靠性：一个服务死机，不会影响其他服务（除非有依赖关系）

• 可扩展性：由于微服务可独立部署，针对不同微服务需要的资源进行扩展

• 持续交付与持续部署，一个一个服务的上线

• 更容易采纳新的技术

缺点：

• 服务拆分的复杂性

• 分布式系统复杂性 (服务发现、编排、监控、熔断)

五、微服务架构与单体架构的适用性

• 康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。
  • 也就是软件的结构要和公司的业务团队的结构类似。小公司，只有一个技术团队，那么就适合单体架构，大公司，多个业务技术团队协作，那么就适合微服务架构多个服务协作。

六 微服务架构设计原则——高内聚、松耦合

【设计模式】理解高内聚、松耦合_A minor的博客-CSDN博客_松耦合设计

• 高内聚：相近功能放到同一个服务中，不相近的功能放在不同的服务中

• 松耦合：服务与服务之间依赖关系简单清晰

  

Uber打车应用

Microservice Architecture — Learn, Build, and Deploy Applications - DZone Microservices

除了那个云智能监控应用是AI服务，我又做了两个微服务的应用场景，第一个是这个打车应用，这是国外的Ｕｂｅｒ公司采用的架构，跟国内的滴滴差不多。这个打车应用的主要业务逻辑就是乘客通过客户端下单，可以是即时出行或者是预约出行，司机通过后台指派的订单信息去接送乘客。 当订单结束后，乘客需要付给系统相应的乘车费用，司机再收到系统发给司机的乘车费用。

如下图所示，左边还是单体架构，讲乘客管理，司机管理，行程管理，账单支付通知等业务功能全部放在同一个应用程序中，还有一个统一的数据库，然后外接一些第三方服务，比如付款适配器，就是接入像支付宝这种的第三方支付方式，以及短信适配器，比如是接入中国移动提供的短信服务。然后这个整体架构通过网络接口给司机和乘客提供相应的打车，付款，通知等服务。

右图则是根据微服务对不同的业务功能进行拆分，拆分为一个个小的服务应用，不同的服务之间通过网络接口进行通信与交换信息，

考虑空气污染的道路收费系统

背景就是开车可能会污染环境，这里可能指的是普通的燃油车，污染环境就需要治理环境，治理环境就需要钱。所以考虑对开车收费，收的钱用来治理环境。国内的方案是只要买车就交车辆购置税，车辆购置税跟排量有关。这篇论文就提出了，上路才交钱，开多远就教多少钱这种方案。

背景说完了，这个考虑空气污染的道路收费系统 ，就是汽车上传GPS信息到云端进行地图匹配，将接收的GPS信息映射为行驶路线，然后通过污染匹配，根据空气污染数据库得到行驶路线的污染等级，然后传给收费计算服务，根据行驶路线计算每个车的通行费。

左图依然是用单体架构部署时的业务逻辑。右图则是讲业务逻辑拆分成多个微服务，不同服务之间通过接口通信。