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