part-one-microservices

microservices

微服务架构提供一个拆分大型应用为较小可相互影响通信的服务的手段。从整体拆分，每个服务可独立交付， 使得每个服务可独立的部署， 升级 ， 缩小， 和替代。服务间通信通常通过网络连接HTTP 调研（request/response). [Web sockets](),
[message queues]() , [pub/sub](), 和 [remote procedure calls(RPC)]() 也可以被用于连接独立组建。

每个独立服务专注于一个单一任务， 通常按业务单元分离， 由 RESTful 协议管理。

课程目标是详细介绍微服务的方式开发应用。 少谈为什么， 专注怎么做。 微服务很难。 它有大量的挑战和问题很难解决。 开始拆分大型应用前记住这一点。

利

关注隔离

服务清晰的分离使开发更专注他们的特长领域，比如语言，框架，依赖， 工具和构建管道。

例如， 一个前端 JavaScript 工程师可开发面向客户的视图，不需要理解后端 API 的代码实现。 可自由选择语言和框架，只需要通过 AJAX 请求来消费 RESTful API来与后端通信。换句话说， 因为通过 APIs 通信开发者可以将一个服务看作一个黑箱。实际的实现和复杂被隐藏。

也就是说， 这是一个好注意来创建一些组织标准来确保每个团队可以一起发挥作用。例如代码质量，风格检查，代码检查， API 设计。

清晰的分离意味着错误可最大限度的定位到开发者所工作的服务。使你可以安排初级开发到较不严格的服务即使他挂掉了对应服务， 剩余整体应用不受影响。

可独立部署意味着更少的耦合使得规模化更容易。 也有助于消除一个团队堆另一个团队依赖完成的等待。

更小的代码库

不需要理解整个系统，小代码库更容易理解。只要有固定的必要 API 设计， 微服务栈的应用可以更快部署，更容易测试， 重构， 和规模化。服务保持一致的开发标准很重要，开发可以更容易从一个服务到另外一个。

加速反馈回路

在微服务中，开发通常掌握应用从立项到交付的整个生命周期。使团队不需要绑定特定的技术栈--像客户端UI,服务端等--团队可以更聚焦产品。自己为交付应用到用户负责。 因此， 应用如何在真实环境运行更清晰可见。这加速反馈循环，更容易修复 bug 和迭代。

弊端

设计复杂

决定拆分应用为微服务并不是个轻松的任务。 通常在整个大项目更容易重构成独立模块。

一旦拆分一个服务就无法回头。

网络复杂

通常一个大型应用所有事情发生于同一线程。 不需要每次调用其它服务。只要你把应用拆分成微服务， 你会发现你将不得不进行网络调用， 之前你只需要调用某一函数。

这可能导致问题，特别是多个应用需要和另外一个通信， 导致乒乓效应。 不得不说明服务全面下降的原因。

基础设施

多服务将代码库复杂度转移到了平台和基础设施。 这可能很昂贵。
另外你不得不使用正确的工具和适当的人力资源管理。

数据持久化

多数应用有状态曾， 像数据库和任务队列。 微服务站也需要记录服务部署地点和实例数量。 当一个实际服务实例启动，可合适的分配路由流量。 这通常称为 [service discovery]().

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

隔离特定服务的状态使得它分享和复制机器困难。你通常不得不处理
不同来源且频繁调整的情况，这归结为设计原因。

集成测试

通常， 使用微服务架构开发应用， 你无法完整的测试所有服务知道你部署到一个预发或生产服务器。这获得反馈的时间太长。 幸运的是， Docker 能通过更容易的连接本地独立小应用服务来帮助加速这一个进程。

日志，监控， 和调试也更难了。