现在大型网络服务的架构都使用微服务架构设计，是什么让微服务架构这么流行？什么是微服务？

什么是微服务

微服务(Microservice)是一种分布式系统的做法。传统的单体式服务(Monolithic)中，通常使用程序模块化的方式将功能进行区隔，但随着系统增长、功能增加的情况下，会变得越来越难以维护、修复。微服务将单体式系统拆分为多个较小的服务各司其职，让各服务聚焦在自身的功能上，彼此间藉由通讯协议(最常使用的是HTTP协议)传递讯息以达成整体系统的串接。在Docker快速席卷IT界后，藉由将服务封装在容器中，微服务更容易被部署到并扩展不同的主机上。

微服务的好处

微服务有以下好处：

• 技术异质性：在拆分成多个单一小模块的情况下，各模块团队可选择各自适合或习惯的程序语言和相关工具，而不必整间公司只使用单一技术。某个模块需要特别提升效能时，可选择对平行加速较擅长的Golang。对图学计算或社群网络时，可选择图数据库(Graph DB)来优化。
• 弹性：传统单体式架构运行的系统如果服务失败，整个系统会无法运作。微服务架构中的单一服务失败时，其他服务仍可正常运作，可避免全面性的失败。
• 水平扩展：单体式架构扩展时，会因系统过于庞大，消耗过多的系统资源而难以扩展。微服务可以只扩展需要扩展的几个服务，依照需求控制每个服务的副本数。
• 容易部署：单体式架构变更程序代码时，整个系统都必须重新测试，并重新部署，运行失败时，可能需要大量的还原才能恢复旧版本的运行。微服务可针对单一服务进行升级，若运行中出问题可将其直接换回旧版本而不影响其他系统的运作。

微服务的不足

微服务架构并非万灵丹，在享有微服务很多方便的特性时，整个团队需要付出更多的努力使这些服务稳定运行。

首先最重要的是测试。微服务的测试变得更加复杂，在测试一项功能时往往会和多个服务沟通运作，整合测试时需要启动相关的服务才能进行测试，撰写测试程序时也需要进行端对端(End-to-End)测试(至少有Stub服务)。

其次是监控。单体式架构在服务运行失败时问题相对单纯，可能重新启动运行失败的服务即可正常运作。微服务架构当服务个数增加并运行在多台主机上时，更需要有良好的监控方式来确保所有服务都正常运作。

数据库的分布式交易也是一个极大的难题。单体式架构在处理数据库交易时通常只有一个数据库需要处理。当每个微服务各自拥有各自的数据库但又需要确保每个服务写入数据库的数据都正确时就需要面对极为复杂的分布式交易。

总结

微服务架构带给了研发团队诸多的便利性，但若团队技术水平、沟通协调并未跟进，很可能会造成很多维运上的灾难。要维持微服务良好的运作，各微服务团队需要付出更多的心力在人与人的沟通和服务与服务的沟通。在容器架构的兴起后，微服务更成为目前锐不可当趋势。

图片来源：

http://dockerone.com/uploads/article/20150524/89d9bfed11ff35943269b24b23b866b1.png

http://dockerone.com/uploads/article/20150524/858f9ae6c861c8c93cd5379be54f9fc1.png

作者:德鸿科技 研发部 Tony