Node.js微服务 1 ： 微服务架构

    2015年，随着以Docker为代表的容器技术的突飞猛进，微服务的部署难题得到解决，甚至有人将2015年称为微服务架构元年。

    作为一本微服务入门的实践指南，本书采用了Node.js和以Seneca、PM2为主的现代框架来进行阐述。

    代码http://www.broadview.com.cn/book/2484

1.1 微服务应运而生

     通常，在一家公司随着业务需求的增长而逐步发展的过程中，前期往往是以单块架构的方式来组织系统的。因为对于软件的初期构建来说，单块架构的方式是最容易且最高效的。但是若干年后，受限于前期既有单块软件系统内部的耦合性，向该系统添加新功能变得越来越艰难。

     单块软件：现在的问题是，并不是所有的公司都能提前对软件系统做好规划。相比于提前规划，很多公司一直以来都是基于自然增长的方式来构建软件系统的，鲜有软件组件会根据业务关系的紧密度来对业务流进行分类。不难发现，大多数公司都只有两个大的软件组件：面向用户的网站和内部的管理系统。我们通常将这种架构方式称为单块软件架构。

     一部分这类公司在尝试扩充团队的时候，面临了巨大的挑战。协调好多个团队来对单个软件组进行构建、部署以及维护是一件相当艰巨的任务。系统发布与bug重复引入之间的冲突往往是家常便饭，这些问题消耗了团队大量的精力。解决该问题的一个方案是将单块软件拆分成微服务。每个团队都专职从事某个相对较小模块的维护，且这些组件也都是自治且互相隔离的。这样一来，我们便可以独立地对这些组件进行版本化、更新以及部署，从而不会牵扯公司的其他系统。

     现实世界中的微服务：一个自治的工作单元，它可以执行某个任务且不干涉系统的其他部分，就好比公司中的某个专职的工作职位。

1.2 面向微服务的架构

     弹性、可组合性以及灵活性都是面向微服务架构设计的关键原则。

     不足之处：

• 网络延迟：微服务具有分布式的特性，从而无可避免地会存在网络延迟。
• 运维负担：更多的服务器也意味着需要更多的维护工作。
• 最终一致性：在一个对事务性要求较高的系统中，考虑到实现的局限性，各个节点在某一段时间内可能会出现数据不一致。

1.3 关键的好处

    设计原则：

• 微服务是一系列参考公司流程模型而分拆出来的业务单元。
• 它们是一系列包含了业务逻辑并能采用简单信道和协议与之进行通信的智能端点。
• 根据定义，面向微服务的架构是去中心化的，从而可以构建出健壮和具有弹性的软件。

    从组件到业务单元：尽可能保持组件和软件其他部分的低耦合，这样它才能作为一个独立的单元进行工作。

    智能的服务，愚蠢的通信管道：过去人们花费了大量精力来创建智能的通信机制，BPEL（业务流程执行语言），它专注围绕各业务环节之间的衔接行为，而非通信行为本身。这样一来便在通信协议中引入了一定程度的复杂度，使得应用的业务逻辑从端点渗透到了通信协议之中，从而导致了端点之间出现了一定程度的耦合。应该将业务逻辑限定在各个端点之内，而不是任由其渗透到通信信道之中，这样的系统更便于测试与扩展。

    HTTP通常是用以构建面向微服务的软件的最广泛的协议，而另一个值得我们关注且需要进一步探索的选项是使用队列来简化端点之间的通信，比如RabbitMQ和Kafka。 

    队列技术以缓冲的形式为我们提供了一种管理通信的全新方式，它对高度事务性系统中消息确认机制的复杂性进行了封装。

    去中心化：微服务的目标是去中心化。相比于构建超大的数据库，它选择根据前文提到的业务单元来对数据进行拆分。

    ACID原则：要么所有调用（事务）都成功，要么什么都不做。

    技术对比：可以选择最合适的技术来做相对应的工作。

    多微才是足够的微：常规而言，微服务应该小到足够在一个sprint之内完成开发。

    关键好处：弹性、可伸缩性、技术多样性、可替换性、独立性、易于部署。

1.4 SOA与微服务的比较

    面向服务架构（SOA）已经存在有些年头了，这是一种用于设计软件的伟大原则。每个微服务应该在本地存储自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向SOA的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。

1.5 为什么选择Node.js

    API聚合：一项用于将不同功能（插件、方法等）组合成一个接口的高级技术。

    展望Node.js：