微服务与服务团队在Amazon的发展

作者 Jan Stenberg ，译者 邵思华

在早先举办的I Love APIs 2015大会上的一场演讲中，Chris Munns讲述了Amazon如何创建企业级的微服务架构的话题。微服务模式改变了我们创建应用的方式，而要成功地创建与运行这些微服务，团队的结构将起到至关重要的作用。

Munns是Amazon的DevOps部门的业务开发经理，他在演讲中引用了维基百科上微服务的定义，但同时也列举了微服务的4条使用上的限制：

· 单一目的。

· 仅通过API进行连接。

· 通过HTTPS协议进行连接。

· 微服务之间大体以黑盒的方式展现。

Munns将微服务与SOA进行了比较，列举了以下这些差异点。

描述团队的规模有一个著名的术语，即刚好能吃完两只披萨的团队。在Amazon，这样的团队被称为服务团队，他们对于创建过程具有完全的自主权，包括产品的计划、开发工作、运维以及客户支持。他们具备完全的自主权及责任性，同时也负责每日的运维和维护工作。换句话说，谁创建的服务，就由谁负责运行。这意味着质量保证（QA）人员以及运维人员都隶属于服务团队之中。但Munns也提到，承担这一角色的部分员工也有可能由整个组织共享。

对于团队来说，这样的文化意味着很高的自由度，但这些团队将通过以下途径得到授权并保证实施的高标准：

· 全面的培训。

· 由具有20年以上开发经验的员工全面定义各种模式与实践。

· 在业务与技术两方面定期进行衡量指标审查。

· 由内部的专家分享关于新工具、服务与技术的知识。

Munn对于小型团队与微服务在Amazon的发展进行了深入的观察，以了解其重点所在。对于其他打算按照相同方式发展的组织，Munn提出了一些建议：

· 文化 —— 这里要强调一点，自主权与责任是不可分离的，规模越大的团队，其运作速度相对于小型团队将有所下降。团队要坚持卓越产品的标准，但并非坚守做事的方式一成不变。

· 实践 —— Munn提到了持续集成（CI）与持续交付（CD），以及简化运维任务的重要性。

· 工具 —— 这些工具将用于之前所提到的实践、基础设施的管理、指标的设立和监控，以及交流和协作。

Munns最后强调了为服务和客户建立起一种模式的重要性，这将使组织避免重复发明一些相同的基础部件，将精力浪费在通信、授权、防止滥用和服务发现等任务上。他还阐述了构建、托管、服务的指标对于观察基础设施是否按预期运行、SLA是否得到满足等问题的重要性。