目录：
Service Mesh入门—1、微服务架构的痛点
Service Mesh入门—2、服务网格架构

Service Mesh也就是目前主流的网格服务架构，我们先来聊聊微服务架构的痛点。

微服务架构痛点

微服务架构特点

在这里插入图片描述
在这里插入图片描述

  1. 围绕业务，拆分多个独立、微小的服务
  2. 各服务间独立运行、独立部署
  3. 各服务进行集中管理
  4. 各服务可以用不同的语言编写、存储

微服务架构

在这里插入图片描述
从图可以看出，常用的微服务架构分层为：

  1. 网关层（一个）
  2. 业务逻辑层（多个）
  3. 数据访问层（多个）
  4. DB（多个）

微服务架构痛点

1、业务关注服务间“通信”

关注服务通讯，业务迭代速度变慢
在这里插入图片描述

2、基础设施组件升级困难

影响团队的交付能力和交付速度
在这里插入图片描述

3、多编程语言之间的“通讯”问题

业务每种语言一套基础设施，成本大
在这里插入图片描述

应用架构发展方向

现代架构发展趋势

  1. 前后端分离—前端工程与后端工程的解耦
  2. 敏捷开发—产品流程与开发流程的解耦
  3. 微服务—业务代码与业务代码的解耦
  4. DevOps—开发与运维的解耦
    从上可以看出，现代架构发展趋势基本围绕“解耦”。

应用架构发展方向

  1. 业务团队专注于业务逻辑本身
  2. 服务通信交给基础设施团队
  3. 解耦业务研发团队和基础设施团队
  4. 一套基础设施支持多语言
  5. 基础能力从应用程序中下推
  6. 真正做到快速迭代、持续交付

以上就是微服务架构的痛点以及应用架构发展方向，下一个章节我们来详解Service Mesh。

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生