有关微服务架构的争论：更简单还是更复杂？

随着 DevOps、持续交付等理念的深入人心，微服务（Microservices）架构开始走进我们的视野。微服务是用一组小服务的方式来构建一个应用，服务独立运行在不同的进程中，服务之间通过轻量的通讯机制（如 RESTful 接口）来交互，并且服务可以通过自动化部署方式独立部署。正因为微服务架构中的服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库。3 月底，来自 ThoughtWorks 的 James Lewis 和 Martin Fowler 分享了他们对微服务架构的理解以及看法。文章中作者详细介绍了微服务的特点以及相对于传统架构的微服务架构的优势。

在 James 看来，传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，传统的整体（monolithic）风格的架构一般分为三部分：客户端用户界面（HTML 页面和 JavaScript 程序）、数据库、服务端应用程序。服务端程序负责处理 HTTP 请求、执行业务逻辑、加载和更新数据库数据、查询和填充 HTML 页面，这个服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外传统的整体风格的架构在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。

传统的开发模式在分工时往往以技术为单位，比如 UI 团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。

传统的软件开发常常以项目为周期，一旦项目开发完成即交付给运维部门，而在微服务架构中，一个团队应该去把控产品的整个生命周期，而不只是开发，这其实也是 DevOps 的核心理念，所以微服务中的每一个服务都是一个产品，而不是一个项目。

微服务架构抛弃了 ESB 复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用 Restful 的方式。

传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用 Node.js 来开发一个简单的报表页面，使用 C++ 来编写一个实时聊天组件。

微服务架构的引入为多样化持久保存数据提供可能，持久层可以使用传统关系数据库和 NoSQL。不同于传统的应用，微服务架构中，我们可以为每个服务选择一个新的适合业务逻辑的数据库系统，比如 MongoDB、PostgreSQL。这样做的好处是显而易见的，首先我们可以根据业务类型（读多还是写多等）来决定使用哪种类型的数据库，其次这样可以减小单个数据库的负载。

就 James 的文章来看，微服务架构主要有以下几个优点：

1. 每个服务只需要做好一件事，更加专注和简单
2. 用合适的工具来做合适的事情
3. 服务之间是松耦合的
4. 服务的团队之间是相互独立的

James 的文章在社区引起了广泛的讨论，近日，Contino 公司的 CTO Benjamin Wootton 在 highscalability 上撰文表示微服务并没有想象中的那么好，并建议开发者在选用此架构时一定要慎重。Benjamin 认为微服务架构时可能会面临下面一些挑战：

1. 运营开销。更多的服务也就意味着更多的运营，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
2. DevOps 要求。使用微服务架构后，开发团队需要保证一个 Tomcat 集群可用，保证一个数据库可用，这就意味着团队需要高品质的 DevOps 和自动化技术。而现在，这样的全栈式人才很少。
3. 隐式接口。服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
4. 重复劳动。在很多的服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。
5. 分布式系统的复杂性。微服务通过 REST API 或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
6. 事务、异步、测试面临挑战。跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。

每一种架构都有其优缺点，当然微服务也包括在内。我们需要根据项目业务和团队情况来选择合适的架构，微服务才刚刚开始发展，这也是顺应 PaaS、持续交付、DevOps 等新技术理念下的产物，期待微服务架构能得到更广泛的应用。关于微服务，如果您有新的见解，欢迎与我们分享。

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。