构建微服务-第一章-什么是微服务_001概览

长久以来，人们一直都在寻找构建更好的构建系统的方法。人们吸取前人的经验，应用新技术，观察新一波的技术潮流如何从各方面帮助技术公司构建IT系统，让这些公司的客户和开发人员更满意。

Eric Evans的领域驱动设计帮助我们懂得了在我们代码里表示现实世界的重要性，给我们展示了如何更好的给系统建模。持续交付的概念给我们展示了如何更加高效地让我们的系统投入生产，让每一行提交的代码都是可以发布的观念深入人心。我们对网络是如何工作的引导我们更好设计让机器相互交互的方式。Alistair Cockburn的六边形架构的概念指导我们避开分层架构的痛点。虚拟化平台允许我们可以按照我们的意愿准备和调整我们的机器，基础设施的自动化让我们可以处理大规模的机器群。一些大的成功的组织比如Amazon和Google倡导小团队负责他们服务的整个生命周期。最近，Netflix给我们分享了如何构建健壮的大规模系统，这些系统在10年前实现起来非常困难。

微服务从领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小规模自制团队而发展起来，微服务的出现并不是一种发明，而是一种现实中使用的趋势或者模式。

很多组织发现细粒度的微服务架构可以让他们更快地交付软件和使用新技术。微服务架构给了我们很大的自由来影响并且做决定，让我们更快地对影响我们的变更做出反应。

 

什么是微服务？

微服务是小规模的，共同工作的服务。让我们来考虑一下微服务区别于其他架构的特征。

微服务都是小规模的，专注在一个工作上面，从而可以把事情做的更好。

代码库会随着我们添加新的功能而增长，时间长了代码库就会增大变得难以维护，如果有新的需求也不知道需要去修改哪里。虽然我们会分模块来设计代码库，但是边界并不是很明确，相似功能的代码可能会到处都有，导致修改bug或者实现新的功能变得很困难。 

在一个单一系统里，我们通过创建抽象层或者抽象模块，增强内聚，将相关的代码组织在一起。内聚也是微服务的一个重要概念，Robert C. Martin的单一职能原则（将因为同一原因而修改的代码放在一起，分离那些因为不同原因而修改的代码）的由内聚原则发展而来。微服务的独立服务也遵循相同的原则，我们服务的边界聚集在业务的边界上，使其存在于确定的一些功能上。将服务聚焦在明确的边界上，我们避免了服务增长到很大，避免了因服务过大而带来的各种相关的困难。

我们经常会问，多小的规模算小？如果按照多少行代码来计算是有问题的，因为不同语言相同行代码表达的意义有多有少。而且我们也要考虑到相关的依赖，这些依赖也可能包含很多行的代码。而且，有时候，不同法律区域的要求不一样，有的地区的法律要求可能带来更多的复杂度。澳大利亚的Jon Eaves用大约2个星期可以重写这个服务来衡量，但是这个度量方式只能在他自己的领域里起作用。另外一个可能的回答是最够小到不能再小。人们基本都知道他们的系统太大，还可以拆分为更小，如果人们感觉一段代码不能拆分为更小，那么就已经足够小了。

我们的服务是否契合团队结构可以帮我们回答我们的服务是否足够小。如果代码库太大不能被一个小团队管理，很显然要想办法分解。考虑服务是否足够小的时候，我们要考虑到，服务越小，微服务的优点和缺点同时都变大。

自治

我们的微服务是一个独立的实体。他可以是PAAS上一个独立的服务，也可以是操作系统的一个进程。我们应该将多个服务放在同一台机器上面。虽然同一台机器的定义在现在已经很模糊，将服务隔离在不同的机器上会增加成本，但是一个服务放在一个机器上带来的简单性会让我们的分布式系统更容易地实现，新的技术也可以降低这种形式部署带来的挑战。

服务之间的交互都通过网络调用来实现，降低服务之间耦合带来的风险。这些服务可以独立低改动不会影响到其他服务，也应当不需要消费者做任何改动就可以部署新版本。我们应该考虑我们的服务应该暴露什么隐藏什么。如果我们共享太多的内部信息，将会造成消费者跟我们的服务形成耦合，将来我们修改服务的时候会需要客户也进行修改。

我们的服务暴露一个API，各个服务通过这些API互相协作。我们也要考虑什么技术合适实现这些服务保证这些服务不会与消费者耦合。这意味着我们选择技术无关的API来避免技术约束。 

关键优点：

微服务的优点很多，大部分都跟分布式系统有关。能够多大程度上实现这些优势跟人们对分布式系统和SOA的熟练程度。