微服务应该避免协调成本

16-10-11 banq
无论你是在一个大企业工作,还是在努力在创业中成长,速度对市场同样至关重要。我们处于一个全球性的,竞争激烈的数字化市场,通向成功的竞争是激烈的。

在实现过程中,事情变得复杂起来,虽然重要的是速度,但速度却很少是唯一的商业目标。对于大多数企业的安全是同样重要的,有时甚至直接由政府执行,例如在需要的监管行业:医疗保健或金融。

很不幸,速度和安全是自然地对立相反-我们前进得越快,安全性就越差,发展到一定规模,必然带来协调,每一次我们需要在多个团队之间协调一个活动,无论每一个团队是多么小(甚至一个人'团队'数),本质上这是整体进展的放缓。一个装配线流水线最快的速度是以最慢那个环节为基准。

然而,一旦我们确定的协调成本是规模组织的速度杀手,我们可以设计我们的组织文化,这样,最小化跨团队之间协调。微服架构是一种软件体系架构风格和相应的组织文化,应该要做的是:优先最小化协调。

然而,消除协调被明确地称为微服架构的核心价值仍然是罕见的,我们通常认为所有的经常称颂的微服务架构好处实际是这一核心价值的衍生物。

1.技术的异质性:移除需要在多个团队中进行编程语言的协调,包括框架、库和技术平台。

2.分区的可扩展性和独立部署:基本上去除了需要跨整个团队进行系统的各个部分的部署和运维的协调。

3.可组合性和可替换性:去除了需要在不同的团队协调系统部件的生命周期管理的必要性。

在所有微服务问题中,给我们带来最混乱和争议的问题是:“微服务的“微”应该小到怎样才算?”

答案很明显,一旦我们承认微服架构就是避免协调的需要:

一个微服务应小而简单,组织中的任何人可以在琐碎的时间内修改或重写它。

“琐碎的时间”会根据上下文而有所不同,从几个小时到几天,但作为一个经验法则:大多数它不应该超过两个星期。

@inadarei: Microservices Are All About Avoiding Co

    

猜你喜欢