微服务

微服务架构提供了将大型应用拆分为多个可相互作用的更小服务的一种手段.

每个服务独立交付,因此每个服务可以脱离主体,独立部署升级拓展替换.

服务间通信通常依赖HTTP调用网络连接.

Web sockets,

message queues

pub/sub

RPC

也可以用于连接独立组件.

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

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

利

Separation of concerns 关注分离

服务间清晰的分离, 开发可以更容易专注他们的专长领域,比如 语言,框架, 依赖, 工具, 还有 构建管道.

例如, 一个 前端 JavaScript 工程师可以开发面向客户的视图,不需要理解后端 API 之下的代码.他可以自由选择语言框架, 只需要和后端交流通过异步请求消费 RESTful API.

换句话说, 鉴于服务凭借 APIs 通讯开发可以将服务看做一个黑盒, 将实现和复杂隐藏.

也就是说, 这是一个很好的理念来创建全机构的标准来确保每一团队可以一起工作运行--比如代码质检和风格检查, 代码检查, API 设计.

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

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

更小的代码库

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

加速反馈闭环

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

弊

设计复杂

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

一旦你分出去没有回头路.

网络复杂

在一个大块应用,通常所有事在一个单独的线程,所以不需要很多次调用其它服务. 由于你拆分你的应用为微服务, 你会发现你现在不得不将函数调用改为网络调用.

这会导致很多问题特别是如果多个应用需要和其他服务通信, 结果在网络请求方面产生乒乓效应. 你也不得不考虑服务的整体下降.

基础设施 infrastructure

多服务下,复杂转化从数据库到平台和基础设施. 消耗很大. 而且,不得不使用正确的 工具 和适当的人力资源来管理.

数据持久化

多数应用有类似状态层,像数据库任务队列. 微服务栈也需要跟踪服务在哪里销毁和全部被摧毁的实例,这样，当一个特定服务的新实例启动时, 通信量可以适当的调整. 这通常称为服务发现.

由于我们将处理容器, 我们需要特别关注如何处理状态容器因为他们不应下降.

隔离一个特定服务的状态使得他不被分享或复制是一个难以描述的困难. 你不得不经常处理各种不同来源的事实,不得不频繁的调解. 再说一次, 归结为设计.

集成测试

通常, 开发微服务架构, 你不能完整测试所有服务直到你部署到预发或生产服务器. 获取反馈的时间花费太长. 幸运的是, docker 通过更容易的连接小的独立的本地服务有助于加速这一过程.

日志, 监听, 和调试同样困难.

跟多微服务测试, 参考 Testing Strategies in a Microservice Architecture