微服务

深碍√TFBOYSˉ_ 2022-03-07 15:54 482阅读 0赞

微服务架构提供了将大型应用拆分为多个可相互作用的更小服务的一种手段.  
每个服务独立交付,因此每个服务可以脱离主体,独立部署升级拓展替换.  
服务间通信通常依赖HTTP调用网络连接.  
Web sockets,  
message queues  
pub/sub  
RPC  
也可以用于连接独立组件.

每个独立服务专注单一任务,通常按内务单元区分,受 RESTful 规范制约.

课程目标是详述在微服务潮流下开发一款应用. 这里侧重怎么做而较少讨论为什么这么做. 微服务很难. 他们有很多挑战和问题难以解决. 开始拆分你的大块应用前牢记这一点.

# 利 #

## Separation of concerns 关注分离 ##

服务间清晰的分离, 开发可以更容易专注他们的专长领域,比如 语言,框架, 依赖, 工具, 还有 构建管道.  
例如, 一个 前端 JavaScript 工程师可以开发面向客户的视图,不需要理解后端 API 之下的代码.他可以自由选择语言框架, 只需要和后端交流通过异步请求消费 RESTful API.  
换句话说, 鉴于服务凭借 APIs 通讯开发可以将服务看做一个黑盒, 将实现和复杂隐藏.  
也就是说, 这是一个很好的理念来创建全机构的标准来确保每一团队可以一起工作运行--比如代码质检和风格检查, 代码检查, API 设计.

清晰的分离意味着错误最大限度的锁定在开发工作的服务内. 因此,你可以分配给初级程序员非关键服务,即使服务挂掉,整个应用也不受影响.

因为每个服务独立部署,更少的耦合也是的扩展更容易. 对消除团队等待另一个所依赖的团队完成工作现象有一定帮助.

## 更小的代码库 ##

更少代码库对更容易理解有益,因为不需要掌握整个系统. 只需要 固化 API 设计, 这意味着微服务栈中通常可以更快开发更容易测试重构和拓展. 记住, 在所有服务站维护一致的代码标准很重要,因此对于开发中从一个服务转到另一个服务很容易.

## 加速反馈闭环 ##

微服务中,开发掌握应用的整个生命周期,从立项到交付.替换团队调整使用特定的技术集--比如客户端UI, 服务端, 等等. 因为这样他们可以更清晰的看到应用在真是环境中如何使用. 这加速了反馈闭环, 更容易修复 bugs 和迭代.

# 弊 #

## 设计复杂 ##

决定分离你应用的一块到微服务不是一个容易的任务. 通常重构为一个独立的模块在全部大块中更容易, 而不是分出去.  
一旦你分出去没有回头路.

## 网络复杂 ##

在一个大块应用,通常所有事在一个单独的线程,所以不需要很多次调用其它服务. 由于你拆分你的应用为微服务, 你会发现你现在不得不将函数调用改为网络调用.  
这会导致很多问题特别是如果多个应用需要和其他服务通信, 结果在网络请求方面产生乒乓效应. 你也不得不考虑服务的整体下降.

## 基础设施 infrastructure ##