在早先举办的I Love APIs 2015 大会上的一场演讲中，Chris Munns讲述了Amazon 如何创建企业级的微服务架构的话题。微服务模式改变了我们创建应用的方式，而要成功地创建与运行这些微服务，团队的结构将起到至关重要的作用。
Munns 是 Amazon 的 DevOps 部门的业务开发经理，他在演讲中引用了维基百科上微服务的定义，但同时也列举了微服务的 4 条使用上的限制：
Munns 将微服务与 SOA 进行了比较，列举了以下这些差异点。
微服务 SOA 使用大量小组件 存在各别较复杂的组件 业务逻辑存在于单独的服务领域中 业务逻辑可以跨多个领域存在 使用简单的连接协议，例如 HTTP 与 XML 或 JSON 企业服务产总线（ESB）充当了服务之间的层的角色 通过 SDK 与客户端连接 API 使用中间件描述团队的规模有一个著名的术语，即刚好能吃完两只披萨的团队。在 Amazon，这样的团队被称为服务团队，他们对于创建过程具有完全的自主权，包括产品的计划、开发工作、运维以及客户支持。他们具备完全的自主权及责任性，同时也负责每日的运维和维护工作。换句话说，谁创建的服务，就由谁负责运行。这意味着质量保证（QA）人员以及运维人员都隶属于服务团队之中。但 Munns 也提到，承担这一角色的部分员工也有可能由整个组织共享。
对于团队来说，这样的文化意味着很高的自由度，但这些团队将通过以下途径得到授权并保证实施的高标准：
Munn 对于小型团队与微服务在 Amazon 的发展进行了深入的观察，以了解其重点所在。对于其他打算按照相同方式发展的组织，Munn 提出了一些建议：
Munns 最后强调了为服务和客户建立起一种模式的重要性，这将使组织避免重复发明一些相同的基础部件，将精力浪费在通信、授权、防止滥用和服务发现等任务上。他还阐述了构建、托管、服务的指标对于观察基础设施是否按预期运行、SLA 是否得到满足等问题的重要性。
查看英文原文： Microservices and Teams at Amazon
立即免费注册 AWS 账号，获得 12 个月免费套餐： 点击注册
有云计算问题？立刻联系 AWS 云计算专家： 立即联系
