再论微服务架构之七宗罪
2014年年底，塔里克·阿贝卓布（TareqAbedrabbo，OpenCredo首席技术官）发表了一篇题为“”的文章，他在此文确定了微服务架构七种常见的反发展模式。2016年一月，来自Voxxed的Danial Bryant发表了该文章的最终版，结合原文以及自己的经验对此文做了进一步的更新。
两人讨论的第一个问题都是构建错误的东西。就像Abedrabbo文章说的那样，可能是由于在定义项目范围和目标时含糊不清所造成的，或者像Bryant说的，试图利用最新的技术，而不是使用最适合特定目标的技术。这两种情况都会导致额外的、不必要的复杂性，因为它们都未集中于项目的最终目标。
不实施契约优先（contract-first）设计方法是项目误入歧途的另一种途径。一个好的服务契约允许开发者专注于微服务是在做什么，而不是专注于它是如何实现的，确定总体目标才是重中之重。
技术实现的细节仍需要解决，Abedrabbo和Bryant两者的文章都提出了通过把单体架构概念运用到微服务架构上面，用以创建分布式单体架构（distributed monolith）。单体架构和微服务架构的交叉也暴露了一个共享域模型问题。
由于应用程序现在通常由多个微服务组成，因此一个应用程序不再是一个刚性边界的单一实体，就好比传统的单体架构案例。开发者可以采用领域驱动设计（Domain-Driven Design，DDD）方法提供一个核心业务概念的演化模型来解决这一问题，这样会更为合适。
这两篇文章同时也表达了对选择错误、太多选择、以及交换信息通信协议的关注。服务功能应该影响协议，而好的方法则是采用标准化的态度，同时使用面向外部服务的同步协议，以及面向内部服务的异步协议。
Abedrabbo强调引进实践证明的DevOps的重要性，正如微服务许可的那样，从一开始就发挥连续传送管道的优势。它从早期开始就支持验收、回归和性能测试自动化，Bryant延续这一主题是为了确保系统在快速移动并经常波动的微服务世界中支持测试。
DevOps这一概念贯彻于Bryant的文章之中，鼓励操作者或系统管理员之间的相互理解。他建议，员工必须接受培训，以应对现实生活中的灾难恢复，这样问题和成功可以通过整个团队进行共享。
人类因素（human factor）是原文的最后一点。微服务可以简化开发并且促进协作精神，但习惯于传统的、大规模的、充满筒仓和政治组织的开发者，对于如何在运行时表现图片服务不可能有更深、更广泛的理解。企业则可以通过投资开发商和鼓励广大组织合作以建立更好的、可持续的、能够利用微服务能力的系统，从而解决这一问题。
原文链接：7 Deadly Sins of a Microservices Architecture
译者：刘帝伟 审核：赵屹华
责编：周建丁（[email protected]）