面向服务架构 (SOA) 带给我们的思考不仅是拆分大型的系统为个性化的服务，还包括使用集中控制和编排工具去构建生产者驱动的庞大服务。 Rebecca Parsons 在 QCon 伦敦大会的演讲中指出，微服务带我们重新思考为什么SOA 是有道理的这一基本概念。他谈到了如何将微服务作为推动者，使系统更加灵活地应对业务预期的速度和规模上的变化，以及为什么一直以来持续交付（CD）适应微服务的能力如此重要。
ThoughtWorks 的 CTO、Parsons 认同 SOA 鼓励了更多人去接受最终一致性和使用其他类型的数据库取代关系型数据库，但在放弃事务的ACID 这点上还存在很多阻力和不决。
当将目光移到微服务架构时，Parsons 强调，无论是分解现有的单一系统还是开始没有遗留系统的新系统，服务的粒度是至关重要的，建议使用领域驱动设计 （DDD）中定义的限界上下文，找到分离服务的边界，这必须用业务角度，而不是技术角度对业务能力的思考来完成的。内聚性和耦合性、通信模式和数据架构是发现服务的其他因素。通信紧密的部分或者有利于数据共享的部分处于同一服务。
对于Parsons 来说，演化架构是一系列的原则，其中一个重要的原则是如何处理系统中最容易被改变的部分。在单一系统下工作时，为此，我们经常预测会用未来3-5 年来构建系统。今天我们尽可能地拥抱变化，即使变化超出预期。关注于演进是关键的因素，微服务是用于支撑这点的基础的一部分。
微服务上承载了额外的功能以运行部署、管理、监控以及与服务的数量和规模相关的活动。如果没有一个强大的devops 文化，以及开发人员和运营人员之间的密切沟通，这将是场灾难。幸运的是上述功能多半已经在持续交付（CD）中提供，持续交付正致力于简化运营团队对微服务架构的管理。
Parsons 最后强调了微服务不是银弹，并非所有的问题都应该用微服务来解决。
查看英文原文： http://www.infoq.com/news/2015/03/qcon-microservices-architecture
感谢丁晓昀对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论