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 能经过更容易的链接本地独立小应用服务来帮助加速这一个进程。

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