一文详解微服务架构
文章目录
- 一文详解微服务架构
-
- 互联网软件架构演变
- 单体架构
- 集群架构
-
- 单体架构缺陷
- 集群架构优势
- 分布式架构
- 面向服务架构 (SOA)
- 微服务架构
-
- 微服务架构优点
- 微服务架构缺点
- 完整的微服务架构图
- 服务网格
-
- ServiceMesh的定义
- ServiceMesh架构
- ServiceMesh优点
- Istio总体架构
- 完整的服务网格架构
一文详解微服务架构
互联网软件架构演变
单体架构
单体架构，一个项目包含所有功能的应用程序，我们通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。
单体应用架构图如下
优点
便于共享：包含所有功能，便于在团队之间共享。
易于测试：一旦部署，所有服务都可以使用了，简化测试过程，没有额外依赖。
易于部署：只需将单个文件复制到单个目录下。
小项目首选,开发成本低，架构简单
缺点
复杂性高：由于是单个归档文件，整个项目包含很多模块，模块边界模糊，依赖关系不清晰，代码混轮堆在一起，使得整个项目非常复杂，编译时间更长。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩
技术栈受限：无法利用多技术栈的优点
集群架构
集群架构就是把代码集群化部署到台服务器上,通过 nginx/apach 等网络服务器 做负载均衡,请求转发，反向代理等
单体架构缺陷
1、单点故障 单机部署很容易出现服务挂了之后，没有备用节点，从而影响用户使用。单机对外提供服务，风险很大，服务器任何故障都可能引起整个服务的不可用。
2、性能瓶颈 单机遇到资源瓶颈时，要想支持更大的用户量，性能有较大的提升，一般是优化业务和增加服务器配置。然而这么做只能是杯水车薪，成本巨大并且效果非常有限。而集群部署通过部署多个服务节点水平扩展服务的性能，成倍的增加服务器性能，而且支持动态扩展。
集群架构优势
1、高可用性。提高服务的可用性，只要有一个服务可用就能对外提供服务。高可用性是指，在不需要操作者干预的情况下，防止系统发生故障或从故障中自动恢复的能力。通过把故障服务器上的应用程序转移到备份服务器上运行，集群系统能够把正常运行时间提高到大于99.9%，大大减少服务器和应用程序的停机时间。
2、吞吐量。增加吞吐量，并发量，支持更大的用户量。
3、易扩展。也叫可伸缩性，可伸缩性体现在节点数量的调整，在预知流量增大的情况下，可以提前增加节点
分布式架构
分布式架构也叫垂直架构,是对于单体架构的拆分,把大项目拆成单个项目结构
分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。
逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
优点：
- 避免了单体架构的无限扩大
- 技术栈不再受到限制
缺点:
- 部分功能在每一个服务端中冗余，具有一定的瓶颈
- 系统性能扩展需要通过集群节点扩展，成本较高
面向服务架构 (SOA)
SOA是按照业务将单体应用垂直拆分多个独立的服务，通过消息总线ESB交互，每个服务还是单体服务
SOA 是面向服务的架构思想，其实微服务也同样，只是两者的侧重点有些差别：
- 微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想。
- SOA 架构则是指一种拆分服务并使服务接口访问变得统一的架构思想。
SOA架构中包含了微服务的思想
优点:
- 将重复性的功能抽取成了对应的服务, 提高了系统的可重用性
- ESB 减少了系统接口的耦合问题
缺点:
- 系统与服务界限模糊, 开发难度加大
- ESB 服务接口协议不固定, 不利于系统维护
- 抽取粒度较大, 存在一定的耦合性
微服务架构
微服务架构 = SOA架构 + 水平拆分的架构
微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构访问方式: 可以是基于 restful 规范的 Rest API 也可以选用 rpc，面向用户开放一套API Gateway
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
微服务架构优点
1 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰，代码量较少。开发和维护单个微服务相对简单
2 单个微服务启动较快
3 局部修改容易部署：单体应用只要修改，就要重新部署整个应用。对某个微服务进行修改，只需要重新部署这个服务即可
按需伸缩：可根据需求，实现细粒度的扩展
微服务架构缺点
1 运维需求高
2 使用微服务构建的是分布式系统。系统容错、网络延迟、分布式事务等都会带来巨大问题。
3 接口调整成本高，微服务之间通过接口进行通信。修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整
完整的微服务架构图
DNS解析 静态资源 动态接口数据
服务网格
服务网格 同上述架构不同的是，这是一个部署架构而不是开发架构, 开发人员开发还是采用微服务架构开发。运维部署采用 服务网格 架构
ServiceMesh的定义
Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递
微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信
服务网格是一个基础设施层，用于处理服务间通信。元原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。
在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。
服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。
它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理组件组成。
管理组件被称为控制层或控制平面（control plane），负责与控制平面中的代理通信，下发策略和配置。
代理在服务网格中被称为数据层或数据平面（data plane），直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
一个典型的服务网格部署网络结构图如下：
其中绿色方块为应用服务，蓝色方块为 Sidecar Proxy，应用服务之间通过 Sidecar Proxy 进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了 Service Mesh。
ServiceMesh架构
实现业务服务与基础服务解耦，业务团队仅仅关注业务开发即可，基础服务交给基础服务团队完成
ServiceMesh优点
1 ServiceMesh独立进程，独立升级
2 业务团队专注于业务逻辑本身
3 一套基础设施支持多语言开发
4 业务团队和基础设施团队物理解耦
Istio总体架构
1 Istio服务网格逻辑上分为数据面板（执行者）和控制面板（指挥者）
2 数据面板由一组智能代理（Envoy）组成，代理部署为Sidecar,调解和控制微服务之间所有的网络通信
3 控制面板负责管理和配置代理来路由流量，以及在运行执行策略
完整的服务网格架构
