微服务架构（一）：微服务架构是什么？

读完全文需要10min

通常跟微服务相对的是单体应用（即将所有功能都打包成在一个独立单元的应用程序）。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。

最初的需求

随着业务发展。。。

增加客户端类型和数据分析、商品促销等服务

上述架构的弊端：

• 重复造轮子：Web端和移动端有很多业务重复的代码。
• 数据共享问题：数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。
• 后台性能问题：管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。
• 数据库性能问题：所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。

是时候做出改变了

这个阶段只是将服务分开了，数据库依然是共用的，所以一些烟囱式系统的缺点仍然存在：

1. 数据库成为性能瓶颈，并且有单点故障的风险。
2. 数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。
3. 数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整。

如果一直保持共用数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此小明和小红一鼓作气，把数据库也拆分了。所有持久化层相互隔离，由各个服务自己负责。另外，为了提高系统的实时性，加入了消息队列机制。架构如下：

微服务架构容易出现的问题：

监控 - 发现故障的征兆

定位问题 - 链路跟踪

Istio文档里的链路跟踪

分析问题 - 日志分析

网关 - 权限控制，服务治理

参考文章：
为什么像王者荣耀这样的游戏 Server 不愿意使用微服务？

什么是微服务架构？