1.1.1 单体应用代码库庞大，不易管理。
1.1.2 单体服务耦合度高，部署困难，一个组件修改导致整个应用部署。
1.1.3 单体服务扩展困难，各个服务对资源要求不一样，有的内存密集型有的CPU密集型，组件无法单独扩展。
1.1.4 阻碍快速开发，随着业务增加，单体服务会变得越来越复杂庞大，开发团队互相耦合度高，不能做到独立开发，业务上线缓慢。
1.1.5 技术栈道使用单一，引入新的技术栈困难。
1.2.1 服务组件化，每个服务单独开发部署，升级。
1.2.2 去中心化，通过采用契约化的接口调用，无需关注组件内部实现。
1.2.3 数据管理独立，各自服务独自管理自有数据库。
1.2.4 基础设施自动化，测试，部署自动化。
1.2.5 容错设计，其中一个服务挂掉，不会影响整个应用。
当然微服务的使用可以解决传统单体服务很多弊端，但使用了微服务也不是就万事大吉了，引入微服务的最大挑战在于如何高效地管理微服务，以及保证复杂网络中微服务的可靠性，提供尽可能高的SLA。主要实现微服务的稳定、可靠、可扩展、容错及灾难预防、性能、监控、日志处理等。
由于从单体服务到微服务的拆分过程，导致各个应用分布在不同节点，构成一个庞大的分布式系统，其可靠性网络通信对微服务构成很大影响。网络的不稳定性等因素使得构建一个高可用、弹性的分布式系统很关键。
事实上，业界在多年的技术积累中已经提出了很多有助于提高系统可用性和弹性的通用性技术手段，如下所示：
- 超时，超时使得访问不会无限等待。
- 重试，有效地解决访问服务发生间隙性的故障
- 熔断，避免请求发送到无效或者不健康的服务上面。
- 限速节流
- 动态服务发现
- 负载均衡
- 运行时动态路由
- 安全通信
- 运行时指标及分布式跟踪
所以要实现上述功能保证服务的可靠，需要使用相关技术来达到整个微服务系统满足高SLA要求。当然如果每个单体服务都采用上面的技术手段来完成网络通信的可靠性，会存在很多弊端例如耦合度高，模块复用率低运维难度大。因此业界通过参考OSI七层模型，将公用的库设计为位于网络栈和应用业务逻辑层之间的独立层，即透明网络代理，作为独立的运行单元，与业务不再直接紧密联系。通过独立层的网络代理实现负载均衡、服务发现、熔断等功能，该透明代理就是我们今天结介绍的Service Mesh。
service mesh是由Buoyant公司CEO William Morgan发起的，他对service mesh定义：专用基础设施层，独立的运行单元；包括数据平面和控制平面；轻量级透明代理；处理服务间的通信；可靠地交付请求；与服务一起部署。
原文：https://www.cnblogs.com/stay-foolisher/p/10422971.html
