(微服务)不就是写一堆小的程序么?
某一天,你正在寻找一种新的方式来重构整个代码库。您考虑过使用一种新的语言,或者在另一个云服务商上进行部署,又或者是使用一种更好的编程模式。之后您找到了它 - 微服务。突然,你发现你可以同时实现这三种方式。
对于初学者来说,“微服务”是一种架构模式,其中,一个应用程序是由多个松散耦合的服务组成,这些服务都可以独立部署。
依你所见,这个架构可以解决你所有的麻烦:
下面我将给出三个论点,为什么微服务不是一件容易的事。我确实认为它们对于构建大型和可扩展的系统很有用,但是必须认识到采用它们的时候会产生的操作和技术上的债务。
一般开始编写微服务的方式就是采用标准的应用程序框架,并使用这个框架来编写一些实用的服务。使用Django,Rails,.Net Core和Spring Boot这些技术的团队,并且肯定不会将其视为反模式。您可能需要针对诸如推送通知,图像大小调整以及域逻辑隔离位之类的功能的服务。
但是问题就出在,有一些元素是需要在多个代码库中标准化的。例如:
您可以通过创建共享库或者一次次重复实现来实现这些逻辑的标准化,但是这存在两个问题:
1. 如果对共享库进行更改,你所有的服务不会自动更新共享库的版本。这使得一些安全性的修复可能变的很难覆盖到所有的服务。这也使得大家不愿意去优化这些共享库。
2. 采用新技术或者新语言,将会导致在开始之前,你便需要为新技术创建或者维护新的库
本·克里斯滕森(Ben Christensen)的演讲 中也提出了类似的论据,他在演讲中讨论了创建“分布式整体”的风险。这是一个不公开的视频,已链接到Monzo的博客文章。
我认为Monzo的博客也提示了一个解决思路。他们正在考虑为所有的“共享基础设施”例如数据库和消息队列构建服务。这使得所有跨领域服务依赖关系都可以用API来解决而不是使用共享代码库。这的确很整洁,但是显然需要很多工作。
不需要多说,当你需要部署一大堆服务的时候,持续集成和部署将会令人头痛,这里有两个例子:
对于以上问题,一个微服务工程师可能会配置一大堆 .yaml
文件,或者使用一个容器编排框架,例如Kubernetes,但是我不会使用Kubernetes,除非我能请一个专门的工程师来管理Kubernetes。
这些问题都不是不可克服的。事实上,我很期待Knative产品(如Google Cloud的Cloud Run)能将无服务器范式的元素带到更传统的微服务部署中。同样,CI/CD的问题也可以由一个聪明开发团队来解决。
但是,同样,这并不容易,需要合理规划。
如果采用微服务架构,那么在写代码的思路上做出重大改变。
下面是一些例子:
公平地说,以上三点可能是大多数架构中部署时需要考虑的事情。然而,微服务可能意味着你的每个服务都需要无数次面对这些问题。
微服务有其适用的时机和地方,但其进入门槛比许多人认为的要高得多。这种架构是可以逐步采用的,但是在设计和规划阶段需要付出大量的努力和专业知识就才能开始采用。
-----
【原文链接】 Why Microservices Should Scare You More
译者介绍 Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。