在单体架构下,会很是依赖于项目一开始对技术的选择,一旦选择了个技术栈,以后几年都会被绑定在这样个技术栈下,很难应对变化。给咱们提供了一个更细粒度使用技术的可能在不一样的服务里可使用彻底不一样的技术栈不一样的语言、框架甚至数据库,真正作到用最适合的技术解决最适合的问题,从而让咱们能够更加敏捷地响应需求和市场的变化提升了竞争力。数据库
弹性弹性工程学的一个关键概念是舱壁。若是系统中的一个组件不可用了,但并无致使级联故障,那么系统的其余部分还能够正常运行。服务边界就是一个很显然的舱壁。在单块系统中,若是服务不可用,那么全部的功能都会不可用。对于单块服务的系统而言,能够经过将一样的实例运行在不一样的机器上来下降功能彻底不可用的几率,然而微服务系统自己就可以很好地处理服务不可用和功能降级问题。架构
庞大的单块服务只能做为一个总体进行扩展即便系统中只有一小部分存在性能问题,也须要对整个服务进行扩展。若是使用较小的多个服务,则能够只对须要扩展的服务进行扩展,这样就能够把那些不须要扩展的服务运行在更小的、性能稍差的硬件上。框架
在有几百万行代码的单块应用程序中,即便只修改了一行代码,也须要从新部署整个应用程序才可以发布该变动。这种部署的影响很大、风险很高,所以相关千系人不敢轻易作部署。因而在实际操做中,部署的频率就会变得很低。这意味着在两次发布之间咱们对软件作了不少功能加强,但直到最后一刻才把这些大量的变动一次性发布到生产环境中。这时,另一个问题就显现出来了:两次发布之间的差别越大,出错的可能性就更大在微服务架构中,各个服务的部署是独立的这样就能够更快地对特定部分的代码进行部署。若是真的出了问题,也只会影响一个服务,而且容易快速回滚,这也意味着客户能够更快地使用咱们开发的新功能。 Amazon和 Netflix等组织采用这种架构主要就是基于上述考虑。这种架构很好地清除了软件发布过程当中的种种障碍。微服务部署领域的技术在过去几年时间里发生了巨大的变化,第6章会对该话题作更深刻的讨论。分布式
咱们经历过太多因为团队和代码库过大引发问题的状况。当团队是分布式的时候,问题会更明显。咱们也知道在小型代码库上工做的小团队更加高效。微服务
分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中,根据不一样的目的,人们能够经过不一样的方式使用同一个功能,在考虑客户如何使用该软件时这一点尤为重要。单纯考虑桌面网站或者移动应用程序的时代已通过去了。如今咱们须要考虑的应用程序种类包括Web、原生应用、移动端Web、平板应用及可穿戴设备等,针对每一种都应该考虑如何对已有功能进行组合来实现这些应用。如今不少组织都在作总体考虑,拓展他们与客户交互的渠道,同时也须要相应地调整架构来辅助这种变化的发生。在微服务架构中,系统会开放不少接缝供外部使用。当状况发生改变时,可使用不一样的方式构建应用,而总体化应用程序只能提供一个很是粗粒度的接缝供外部使用。若是想要获得更有用的细化信息,你须要使用榔头撬开它!第5章会讨论如何将已有的单块应用程序分解成为多个微服务,而且达到可重用、可组合的目的。组件化
若是你在一个大中型组织工做,极可能接触过一些庞大而丑陋的遗留系统。这些系统无人敢碰,却对公司业务的运营相当重要。更糟糕的是,这些程序是使用某种奇怪的Fortran变体编写的,而且只能运行在25年前就应该被淘汰的硬件上。为何这些系统直到如今尚未被取代?其实你很清楚答案工做量很大,并且风险很高。当使用多个小规模服务时,从新实现某一个服务或者是直接删除该服务都是相对可操做的。想一想看,在单块系统中你是否会在一天内删掉上百行代码,而且确信不会引起问题?微服务中的多个服务大小类似,因此重写或移除一个或者多个服务的阻碍也很小。使用微服务架构的团队能够在须要时轻易地重写服务,或者删除再也不使用的服务。当个代码库只有几百行时,人们也不会对它有太多感情上的依赖,因此很容易替换它。性能