1. 单体架构
1.1 单体应用
相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起。
1.2 集群架构
随着用户规模和业务量的不断上涨，单个应用服务器将出现性能瓶颈，对于PB级的数据和高并发用户大流量访问，单一或者主备的数据库、文件系统都已经不能满足需求，需要集群化来分担负载。当数据规模达到一定规模，传统关系型数据库性能下滑非常严重，通过分库分表也难以应对，为了支撑海量数据和流量，出现了NoSql数据库，它关注对数据高并发地读写和对海量数据的存储。
同时应用服务器从单体变为集群，客户端也不再是直接接入后端应用，而是转而通过负载均衡设备代理后端多个服务器集群，一方面将访问压力分摊到了多个后端应用上，单个应用不再是性能瓶颈，另一方面可以实现服务路由，以及异常熔断等特性。
为了进一步降低服务端压力，降低客户端访问延迟，客户端与负载均衡设备之间加入CDN对静态资源进行缓存加速，利用GSLB调度体系，将用户请求精准调度至最优接入节点。以达到最优的访问性能。
1.3 分布式架构
同时随着业务场景的复杂化，存储规模越来越庞大。将业务进行拆分并分而治之成为更好的选择。大型的业务场景被细分为单个更小的业务子场景，按照系统业务功能进行划分，例如对于电商系统，按功能维度我们可以拆分为商品中心，订单中心，用户中心，购物车，结算等功能模块。每一个子模块由不同的业务团队负责。每个子业务模块进行独立开发、部署、运维。
随着对业务场景越来越细的划分，模块越来越多，整个应用的复杂度也越来越高，大量的独立子应用对数据库的独立访问，导致后端数据库的压力越来越大，需要将各个子应用的重叠逻辑再进行抽取为独立子服务，子应用服务之间通过RPC或者消息系统进行相互通信，因此出现了分布式应用, 到目前为止的分布式架构已经能够应对大部分高并发，大流量的业务场景。
1.4 单体应用的缺点
上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：
- 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）
- 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
- 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
- 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。
2. 微服务
2.1 微服务概念
微服务架构之前还有一个概念：SOA（Service-Oriented Architecture，面向服务的架构）。人们逐渐认识到SOA可以用来应对臃肿的单块应用程序，从而提高软件的可重用性。它的目标是在不影响其他任何人的情况下透明地替换一个服务，只要替换之后的服务的外部接口没有太大的变化即可。
微服务应该算是SOA的一种演进。从 2014 年开始，得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的兴起，SOA的思想进一步演化，演变为今天我们所熟知的微服务。
微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活。
2.2 微服务架构带来的挑战（没有银弹）
微服务架构虽然解决了旧问题，也引入了新的问题：
- 以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈，而微服务架构整个应用分散成多个服务，定位故障点非常困难
- 在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障
- 服务数量非常多，部署、管理的工作量很大。
2.3 微服务架构
微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
当然微服务的服务治理还涉及很多内容，比如：
- 通过熔断、限流等机制保证高可用；
- 微服务之间调用的负载均衡；
- 服务调用链跟踪等等。
2.4 微服务框架
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo，Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
3. Service Mash
3.1 service mesh概念
使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。
Service Mesh 通过 SideCar 代理转发请求，把微服务框架的相关实现全部集中到 SideCar 中，并通过 Control Plane 控制 SideCar 来实现服务治理的各种功能，这种业务与框架功能解耦的思能够解决框架更新成本高的问题。
Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。即使回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。
3.2 service mesh实现
Istio 是由 Google、IBM、Lyft 等共同开源的 Service Mesh（服务网格）框架，作为云原生时代下承 Kubernetes、上接 Serverless 架构的重要基础设施层，于 2017 年开始进入大众视野。
