微服务专家在#api360微服务峰会2016上的经验分享

微服务 API

摘要

在纽约举行的API Academy #api360微服务峰会上，许多微服务专家发表了他们对于微服务现状、相关架构和组织问题、过程和技术的看法。

正文

在纽约举行的API Academy #api360微服务峰会上，许多微服务专家发表了他们对于微服务现状、相关架构和组织问题、过程和技术的看法。他们分享的主要经验教训包括：为充分利用微服务，需要在技术和组织基础设施支持上进行投入；必须注意理解微服务以业务能力和负责任的自决团队为重点的原则；开发和运维团队必须理解构建和运行健壮的分布式系统的实践。

API Academy的副总裁Matt McLarty在活动开始时比较了汽车和微服务的发展历史。他指出，虽然汽车最初只是业余爱好者的兴趣，但装配线的引入让它成了大众产品。也许可以说，Docker提供了一种类似的方式，可以批量地将应用程序打包到Linux容器中。McLarty继续进行类比，他表示，汽车成功获得广泛应用要归功于基础设施配套，比如州际公路地图、交通灯和加油站，他认为，我们仍然需要发展同等的基础设施，真正实现微服务和容器技术的好处。

Ronnie Mitra是API Academy API设计部门的负责人。他列举了几种行业专家提出的“微服务”定义，认为它们过多地强调了这种架构风格的“规模”方面。必须注意，不要“只是简单地将复杂性排除在系统之外”，并且必须在宏观和微观层面进行设计。Mitra指出，服务边界是微服务架构中最重要的概念，可以帮助管理整个系统演化过程的节奏。组织设计和文化在成功实施微服务方面扮演着重要的角色，虽然在软件开发中总是要平衡速度和安全，但如果做对了，微服务的切分会在这两个方面都带来提升。

Haufe.Group首席技术官Holger Reinhardt介绍了“自动化单体应用（The Automated Monolith）”。他讲述了一个有警示意义的故事——一次几乎失败的从单体应用向微服务的迁移。迁移单体应用程序的最初尝试产生了一系列的问题，包括损失了测试覆盖率、范围蔓延、增加了项目复杂性（一个告诉管理者“我们另外还需要X个开发人员”的主要指标）以及“敏捷变得脆弱（agile becoming fragile）”。Reinhardt回顾了两个重要的概念：一是Martin Fowler提出的微服务的先决条件，主要是围绕自动化；二是来自精益理论的“固化、优化和转换”。同一个团队又进行了另外一次尝试，但更注重自动化，划分了“需要更快修改的”系统部分的迁移优先级，改进了项目管理结构（以“瀑布-敏捷”作为通向真正敏捷的桥梁），并维护所需要的领导力。第二次迁移取得了成功。

接下来，Vijay Alagarasan提供了一个内容翔实的列表——“7种微服务反模式”，InfoQ 之前发表过这篇文章。

1. “内聚混乱（Cohesion Chaos）”——服务必须清楚地与业务能力保持一致，不应该试图做一些超出范围的事。
2. 不重视自动化——持续部署（如果你还没有这样做）是必须投入精力实现的，文化变革也应该是每个企业的目标。
3. 服务架构分层——创建多个技术和物理上的服务层次只会导致复杂性增加，运行时效率降低。
4. 依赖客户签字——交付的每个服务都必须有一个测试套件，该套件应该涵盖所有的服务功能、安全、性能、错误处理以及针对每一个现有消费者和未来消费者的消费驱动测试。
5. 手动配置管理——使用应用程序配置管理工具作为PaaS或持续部署的一部分。
6. 未使用版本控制——制定一个版本控制策略可以使消费者轻松迁移，并确保服务提供者可以透明地部署变更而不影响其他任何人。限制生产环境中并行的大版本数量，并治理它们。
7. 在每个服务中构建网关——在API管理方案上投入精力，集中化部分非功能性问题的管理和监控，这同时也会减少消费者管理若干微服务配置的负担。

午餐之前的环节是由Vanick Digital负责人Lou Powell主持的专题讨论，参与讨论的微服务专家包括jet.com的Erich Ess、Netflix Edge Developer Experience部门负责人Sangeeta Narayanan、Thoughtworks高级顾问Cassandra Shum以及Gilt.com工程部门高级副总裁Adrian Trenaman。专题讨论的主要结论包括：雇佣负责任的软件工程师，为他们提供环境，赋予他们自主权和责任性，以确保交付效率；使用“拓荒者、定居者和城市规划者”模型推动系统、工具和过程的创新和稳定；增强业务涉众和IT之间的协作；发展和培养一种有效的透明文化，共享理解与合作；规划和制定贯穿整个技术栈和组织系统的故障（比如断路和“恢复培训/游戏日环节的事故”）解决方案。

Mike Amundsen是API Academy API架构负责人。他在下午会议开始时指出，创新无处不在，他还援引Joseph Schumpeter的话“创新是经济变革的向度”来说明公司能够快速创新的重要性。Amundsen指出，通过划分工作以及合作解决问题（很像蚂蚁的做法），我们可能可以更快地创新。微服务架构风格可能帮助我们在软件开发中实现这个愿景。Amundsen援引《第五项修练》的观点指出，我们需要构建学习型组织，鼓励试验以及从故障中学习。应该给IT团队时间，让他们拓宽知识面，试验新技术，因为这可能会让相关组织持续创新，“跳过S曲线”这个公司成长期。

CA科技首席顾问Erik Wilde描述了“微服务和Web架构”，他指出，许多人将SOA视为一个“糟糕的词语”。Web服务的最初实现并不是以万维网（WWW）精神为依据，主要关注的是系统架构，而不是生态系统架构。微服务可以视为SOA的下一步演化，并结合了敏捷、持续部署和DevOps的最初原则。Wilde认为，微服务可能会“在规模很大的情况下和谐地提供速度和安全”，但目前还有一些“盲点”，比如如何发现一个大型生态系统（可能需要某种去中心化的目录）中的服务，微服务如何设计、管理和进化才能保证生态圈的健壮和灵活。Wilde在总结中提出了“微服务的3V”：“体量（volume）”——如何获取大规模系统操作的整体视图？“种类（variety）”——作为创建者或者消费者，如何处理不同的服务设计？“速度（velocity）”——随着生态圈的发展，服务及其设计的稳定性如何？

在接下来的环节中，Mike Amundsen采访了Mel Conway，后者根据“60年的人性化工艺”创立了“康威定律”。Mel提供的建议包括：“划分解决方案”——富有表现力的领域专属语言让联合解决方案可以获得更大的回报；“静态有益”——为了让许多人都能够理解应用程序开发，就需要减少（或隐藏）算法；“简化开发人员的生活”——为开发人员提供即时反馈，不要让开发人员区分“编程”语言和“执行”语言；“人性化工艺”——事件驱动应用程序和就地转换系统在概念上可能比传统的编程更容易理解，而让应用程序开发普遍可以理解的方法是利用具有合适工具（很像使用陶工的轮子）的手眼脑系统。

在倒数第二个会议上，Comcast高级研究员Jon Moore介绍了如何“在微服务丛林的局部故障中存活下来”。Moore提出，基于微服务创建应用程序的团队实际上是在构建分布式系统，而这些类型的系统容易发生局部故障。有许多局部故障类型在发起连接的客户端看来是相同的，不管被调用的服务实际上进行了怎样的处理，因此，我们必须开发恰当的迁移策略。Moore提出了三种策略：（1）幂等服务接口——服务调用重试不应该产生意外的副作用。也可以通过有效地缓存响应减少服务的负担，隐藏瞬时错误（潜在的代价是数据过期）；（2）根据临界状态划分——使用异步通信，创建恰当定义的服务边界，提供可选的（回退）方法；（3）尽可能重组——选择粗粒度服务，最小化局部故障，学习识别服务过度细化的预警信号，比如只有一个客户端的服务、紧耦合（服务A的任何修改都会导致服务B的修改）及相关调用。

在那天的最后一场会议上，ReferWell首席技术官Irakli Nadareishvili描述了“微服务盲点”。微服务架构风格的应用一部分是由容器技术的出现所推动，该技术让运行单个隔离的进程非常方便。Nadareishvili指出，微服务社区当前的关注点过多地以代码为中心，相反，他们应该将关注点放在服务边界接口设计上——“服务接口耦合同代码耦合一样有害，会导致整个架构毫无用处”。领域驱动设计（DDD）和有界上下文的概念非常有用，可以帮助开发人员在基于微服务的应用程序内有效地建模。Nadareishvili在总结时指出，基于事件的系统设计技术，比如事件源（ES）和命令查询责任分离（CQRS），在开发微服务系统时非常有效。

关于API Academy #api360峰会的更多信息，可以查看大会网站或者Twitter话题标签#api360。

查看英文原文：Lessons Learned from the #api360 Microservices Summit 2016