单片架构 vs 微服务架构

现在谈及微服务架构的文章、演讲随处可见，似乎所有系统的架构都开始尽情拥抱微服务架构。然而，我们在选择微服务架构之前，一定要问一句“你现在面对的系统，微服务架构是最佳选择吗？”。

任何互联网系统的架构发展到后期，随着复杂度越来越大，那么微服务架构是必然也是最好的选择。但是，系统的架构都是从小到大从简单到复杂演进的，“网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。”所以，微服务架构是否是一个好的选择，实际上要看系统的复杂度来决定的。关于这个问题，在Martin Fowler曾发表的一篇文章《MicroservicePremium》中深刻阐述了这一点，并给出了这张很关键的图：

单 片 架 构

在开发服务器端应用时，人们往往从由这些不同类型的组件组成的模块化六角或者分层结构来下手：

＊ 展示组件——负责处理HTTP请求并使用HTML或JSON/XML进行相应

＊ 业务逻辑组件——应用的商务逻辑

＊ 数据库访问组件——负责数据库访问的数据访问对象

＊ 应用集成组件——与其他服务集成（如通过消息传递或通过REST API）

尽管具有逻辑模块化结构，应用程序仍然作为整体进行打包和部署。

单片结构的优点

＊ 易于开发

＊ 易于测试。比如，端到端的测试可以通过简单地打开应用并使用Selenium来调试UI。

＊ 易于部署。只需要发送一个打包的应用副本至服务器就可以完成部署。

＊ 通过同时在负载均衡器上运行多个副本，轻松完成水平扩展。

在项目的早期阶段单片结构运作良好，且世界上绝大多数现存的大型应用和成功应用都是从单片结构开始发展的。

单片结构的缺点

＊ 简单性使其在应用复杂性和应用尺寸上存在局限性。

＊ 应用程序过大且难于充分理解并快速正确的进行更改。

＊ 应用程序的大小会减慢启动时间。

＊ 每次更新都需要重新部署整个系统。

＊ 不能充分的预知变化会带来的影响，需要大量的手动调试。

＊ 难以进行持续发布。

＊ 可靠性不足，任何模块的小bug（如内存泄露）可能会导致整个进程的奔溃。而且由于应用中的实例都相同，这些bug会影响到整个应用的可用性。

＊ 单片应用对新技术的应用有屏障。框架或者语言的变化会影响整个应用程序，因此在时间和金钱成本上都开销很大。

微 服 务 架 构

微服务架构的想法是将应用程序分成一组组更小，内部连接的应用，而不是搭建一个单片的应用。每一个微服务都是一个小应用程序，且都有自己的六角架构，包括业务逻辑模块以及各种适配器。一些微服务会公开REST,RPC或者基于消息的API且大多数服务都将使用来自其他服务的API。其他的微服务则可能会运用Web UI。

微服务架构极大的影响着应用和数据库之间的关系。每一个服务都有着自己的数据库模式(schema)，而不是和其他服务共用同一个。一方面，这种方式与企业级数据模型的想法不一样。此外，数据重复的情况也时有发生。然而，想要从微服务架构下获利，一个服务使用一个数据库模式是必不可少的，因为这可以增强松耦合性，而且每一个服务可以使用最适合自己需求的数据库，这就是所谓的混合持久化(polyglot persistence)架构。

一些API也会对移动端，桌面端和网页端开放，然而应用却不能直接访问后端服务，而是需要通过一个叫做API网关的“中介”来完成信息传递。API网关负责平衡负载，缓存，访问控制，API计量还有监控等任务。

微服务架构模式对应了立方体可扩展性模型的Y轴。

微服务架构的优点

＊ 应用复杂性的问题被通过将应用分成一个个服务而解决，这样一来，开发速度大幅提升，且应用更易理解和维护。

＊ 使每项服务都可以让专注该服务的团队开发。

＊ 减小了应用新技术的障碍，应用开发者可以自由选择对他们开发的服务有用的任何技术，而不用一直沿用开发周期最早所选择的。

＊ 让每一个微服务都可以独立部署，使得复杂应用的持续交付功能变为可能。

＊ 微服务架构使得每个服务都可以独立扩展。

微服务架构的缺点

＊ 仅仅因为微服务的分布式系统结构就为微服务项目增加了复杂性。开发者需要选择并实现基于消息传递或者RPC的进程间通信机制，并处理“部分故障“和其他分布式计算带来的错误。

＊ 微服务具有分区数据库架构，所以在处理需要在多家不同公司处理的商业交易需要同时在被数家不同公司管理的数据库中更新数据。使用分布式交易通常是不可能的，开发者最终会被要求使用基于一致性的方法来应对，而这对他们来说是一种挑战。

＊ 测试微服务应用也比测试单片式网络应用复杂得多。做一个类似单片应用测试需要启动该服务和所有其依赖的任何服务（或至少打开它们的配置存根）。

＊ 跨服务的更改变得更加的困难了。在单片应用中你只需要简单地更改对应的模块，整合这些改动，并一次性部署它们，而在微服务应用中，需要仔细规划和协调对每个服务的更改。

＊ 部署微服务应用也变得更加复杂。单片应用只需要简单地部署在负载均衡器下一系列相同的服务器上，而微服务应用通常由一大堆服务组成。每一个服务都需要多个运行实例，而每一个实例都需要被调试，部署，扩展和监视。此外，开发者还需要实现“服务发现”机制，因为手动操作是无法达到微服务级别的复杂度的，想要成功部署微服务应用需要高度自动化。

总 结

构建复杂的应用本身就很困难，单片架构则很适合简单，轻型的应用。有建议说所有应用都应从单片架构开始，也有人说如果目标是最终想使用微服务架构的话，则从开始就不应该使用单片架构。但不管如此，最重要的是要理解单片框架，因为它是微服务架构的基础因为每一个服务仍旧是根据单片架构开发的。微服务架构更适用于复杂的，不断升级的应用，但为了达到应用微服务化，会带来一系列的，微服务开发难题和应用实施的挑战。

◆ 参考素材（英文原文）：

http://www.antonkharenko.com/2015/09/monolithic-vs-microservices-architecture.html

关注蓝灯数据更多产品线的微信公众号