微服务有且仅有一种很是专项的功能，经过远程API来提供系统其他功能。举个例子：试想一下仓库的管理系统，这样的系统中微服务可能提供的一些功能有：算法
接收库存数据库
计算新的库存该存到什么地方服务器
计算在仓库内将库存运往正确放置点的路线架构
为仓库员工分配运送路线框架
接收订单分布式
计算仓库内指定一组订单的拣货路线微服务
为仓库员工分配拣货路线性能
以上这些功能(可能还会有更多)都是由单个微服务实现的。每一个微服务都有单独的运行线程，而且能够独立于其余微服务进行部署。一样每一个微服务都有本身的专用数据库，尽管每一个微服务都会与其余微服务协做与沟通。学习
一个系统中的不一样微服务彻底有可能在不一样的平台上实现，一些可能在.NET上，另一些在Erlang，其余的在Node.js上。只要能协调多语言的问题，各个微服务彼此正常沟通，就能奏效。HTTP是良好的沟通选择：上面全部提到的平台，还有不少其余平台都能很好的处理HTTP。固然也有符合微服务沟通规则的其余技术：例如一些队列、一些服务总线还有一些二进制协议。在这些技术当中，HTTP多是支持最普遍的，至关容易理解，并且就像万维网所展现的那样很好用，整体来讲是很好的方案。测试
再次以仓库系统为例：该系统的一个微服务是分配拣货路线微服务。图一展现了“分配拣货路线微服务”从另外一个协做微服务收到的请求：为指定员工设定了下一次的拣货路线。分配拣货线路微服务必须为员工找到合适的线路，而另外一个微服务则完成计算最优路线的工做，分配拣货路线微服务只需收到拣货路线通知并肯定如何为雇员分配路线。在分配拣货路线的微服务中，收到请求——分配指定员工的拣货路线，搜索数据库，找到合适的拣货路线，并从中选择一个返回给微服务调用。
微服务架构是什么?
微服务是一种架构类型，属于轻量级的面向服务体系架构，这些服务都是严格专一于执行同一件事并把它作好。
使用微服务做为主要架构类型的系统是一个拥有大量协调微服务的分布式系统，每一个微服务分管本身的进程。因为微服务之间紧密协做，每一个微服务只提供拼图的一小块，而系统作为完整的做品存在。协做时，各服务彼此经过一个不绑定具体平台的轻量级媒介进行沟通，好比.NET，Java或者Erlang。如前所述，本书中全部微服务之间的沟通都是经过HTTP的，不过还有其余可选方案，好比队列、总线或者相似Thrift的二进制协议。
在构建与维护复杂的服务器端软件系统时，微服务架构类型迅速流行起来。能够想见，这样一来：在传统的面向服务方法和总体架构(monolithic architectures)中，微服务都有大量潜在好处。在运做良好的前提下，微服务在可塑性、可扩展性与弹性方面都具备优点，并容许使用者只花费很短的时间就实现从开始到生产环境部署的过程。
微服务特性
虽然已经说了这么多，不过定义还很模糊。为了缩小微服务的界定范围，咱们先来考察一下微服务的特性。在笔者理解中，微服务这个术语的特性是：
1. 负责单个功能
2. 单独部署
3. 包含一个或多个进程
4. 拥有本身的数据存储
5. 一支小团队就能维护几个微服务
6. 可替换的
这张特性列表不但帮助识别微服务，还可以在发挥微服务优点(一个拥有可塑性、可扩展性与弹性的系统)的前提下协助界定与执行该服务，依次看下去。
负责单个功能
微服务在整个系统中只负责单个功能。这句话分解来讲包含两部份内容：第一，微服务只有单个责任;第二，负责的是功能。单一责任原则有几种描述，其中一个传统的描述是：
“当须要修改某个类的时候缘由有且只有一个("There should never be more than one reason for a class to change.")” -- Robert C. Martin SRP: 单一责任原则
尽管这种说法特别提到了“类”，这一原则却不仅适用于面向对象语言的类层面。经过微服务，这里在服务层面运用单一责任原则。另外一种较新的说法也是描述单一责任原则的：
聚合因同一理由变化的东西，分离因不一样理由而变化的东西。("Gather together the things that change for the same reasons. Separate those things that change for different reasons.")-- Robert C. Martin单一责任原则
这一原则适用于微服务：微服务应当正好实现一个功能。微服务必须只在功能改变时才跟着改变。此外，应当努力让微服务彻底实现相关功能，这样在功能改变时微服务也得跟着改变。
微服务系统的一个功能可能意味着几件事。首先，功能多是业务方面的。业务功能就是系统所完成的、对系统的目的有贡献的事情——好比持续追踪用户的购物车或者计算价格。梳理一个系统拥有的独立业务功能有一个好办法，就是使用Domain Driven Design。第二，有时候功能能够是多个其余微服务须要利用的技术功能——例如集成到一些第三方系统中。技术功能并不是是将系统分解成微服务的主因，而是因为微服务执行业务功能须要一样的技术能力而致使的结果。
独立部署
每一个微服务都应当是单独部署的。也就是说：当你改变一个特定的微服务时，须要可以将微服务的变动部署到生产环境中，而无需部署或触及系统的其余部分。事实上，系统中的其余微服务应当在改动的微服务部署之时，还有新版本部署完成以后继续持续运行。
试想一下电子商务网站：每次购物车微服务发生改变时，都应当能当即进行部署。同时价格计算微服务、推荐微服务、产品目录微服务等等应当继续运行并知足用户的请求。
可以单独部署每一个微服务很是重要，缘由有好几个。其中一点是，在一个微服务系统中有不少微服务，每一个微服务都会与其余几个相协做。各部分的开发工做同时完成，或者不少微服务并行。若是须要按同一步调部署全部或者不少微服务的话，管理部署很快就会变得捉襟见肘，特别是常常会致使高风险部署，这是咱们很但愿避免的。相反咱们但愿可以对每一个微服务进行小变动部署，这样风险会更低。
可以在系统的其余部分继续正常运行的时候部署单个微服务，构建过程必须牢记这一点：每一个微服务必须打包到不一样的构件或程序包中。一样地，部署过程自己还必须支持在其余微服务继续运行之时，独立部署变动的微服务。好比，每次将微服务部署到服务器的过程当中，为了减小停机时间可使用滚动部署的办法。
微服务互动的方式也受到指望独立部署的影响。改变微服务接口必须在大多数状况下向后兼容，这样其余现有的微服务就能够继续按照与旧版本融合的方式与新版本集成了。此外，微服务互动的方式必须有弹性，每一个微服务必须在其余微服务偶尔出错时继续保持最佳运行状态。一个微服务出错——好比由于部署时的短暂停机——必须不影响其余微服务运行，只是形成功能缩减或者进行时间稍长。
包含一个或多个进程
一个微服务由一个或多个进程组成，这个特性有两面性。首先，每一个微服务独立于其余微服务运行;其次，每一个微服务能够拥有不止一个进程。
某微服务独立运行，是因为但愿保持每一个微服务尽量独立于其余微服务继续运行。此外，为了独立部署微服务，那个微服务不能按照其余微服务的方式来运行。再用购物车微服务来举例：若是按照与产品目录微服务相同的方式运行，购物车代码可能对产品目录代码产生负面影响，这表明着购物车微服务与产品目录微服务之间紧密却不受欢迎的耦合。
如今思考一下部署购物车微服务的新版本状况。要么得从新部署产品目录微服务，要么就得有某种动态代码加载功能，来替换正在运行中的购物车代码。前一个选项与微服务独立部署的原则彻底相违背，后一个选项太过复杂并且起码有因为部署购物车微服务而形成产品目录微服务停机的风险。
每一个微服务可能包含不止一个进程，表面来看可能使人惊讶，毕竟这里尝试让每一个微服务尽量简单好控制，那么为何要自找麻烦拥有不止一个进程呢?用电子商务网站作个比方：执行推荐算法会在电子商务网站上展现推荐选项，这些算法都在这个微服务所属的进程中运行，还存储了提供推荐须要的数据。这个数据可能存储在硬盘文件里，不过更有可能存在数据库里，在第二个进程中运行的数据库也属于这个微服务。一个微服务一般拥有2个或以上进程的需求，就是由于微服务须要实现所须要的一切，以提供包含诸如数据存储还有后台处理之类的功能。
拥有本身的数据存储
一个微服务包含数据存储，在该进程中存储所需的数据，正是因为咱们但愿微服务的范围是一个完整的功能。大多数业务功能须要一些数据存储，例如对于产品目录微服务来讲，每一个产品的信息须要存储下来。为了保持产品目录微服务与其余微服务的松散耦合性，存储的产品信息数据彻底包含在产品目录微服务之中。由产品目录微服务肯定什么时候、如何存储产品信息。其余微服务——好比购物车微服务——只能经过产品目录微服务的接口来访问产品信息，而永远不能直接访问产品目录存储。
每一个微服务包含本身的数据存储，这开启了根据每一个微服务需求，为不一样微服务使用不一样数据库技术的可能性。产品目录微服务可能使用SQL服务器来存储产品信息，而购物车微服务可能用Redis来存储每一个用户的购物车信息，推荐微服务则使用Elastic Search索引来提供推荐服务。为每一个微服务所选择的数据库技术是执行的一部分，对其余微服务来说是隐藏的。将数据库技术与每一个微服务需求进行混合配对的好处在于，每一个微服务可使用最适合的数据库。对开发时间、性能和可扩展性颇有好处，不过也带来了成本问题。数据库技术上很是复杂，学习使用和在生产环境上运行一个可靠的数据库都不容易。为微服务选择数据库信息时，应当考虑取舍的问题。不过也要记住，因为微服务拥有本身的数据存储，稍候切换到另外一个数据库也是可行的。
小团队就能维护
到如今本文并未讨论太多微服务的规模问题，虽然微服务中的“微”暗示着这些服务规模很小。但这里并不认为讨论微服务应当有几行代码，需求/用例有多少或者应当执行的功能点有几个这些有什么意义。全部这些取决于微服务所提供功能的复杂性。真正有意义的是考虑维护微服务的工做量。指出微服务规模大小的一条经验法则是：一个5人小团队就应当可以维护几个或者更多的微服务。维护一个微服务包括保持其正常运行并达成目标：开发新的功能、从发展到过大规模的微服务中分解出新的微服务、监控测试与修复bug及其余。考虑到一个小团队应当可以完成几个微服务的全部这些工做，你应当对典型的微服务规模有概念了。
可替换的
一个微服务是可替换的，表明着它能够在合理的时间框架内从头重写。也就是说，维护该微服务的团队能够决定用全新的实现来替代现有的，而且不会打乱正常工做的进程。这条特性也是微服务规模的一条约束：若是一个微服务成长地太大，替代成本就会太高，只有保持小型才能让重写比较现实。
为何团队会决定重写微服务?一个缘由多是代码太乱，另外一个缘由是微服务不能在生产环境中运行良好。尽管这些状况并不是所愿，却出体现了微服务的优点。即使努力构建微服务，时间形成的需求变动可能促使现有的实现方式没法知足需求而须要变动。并且随着时间过去，代码可能会因为初始设计周折太多而变成一团乱麻。性能要求可能会须要大幅提高，而现有设计没法知足。若是一个微服务小到在合理时间框架内便能重写，偶尔出现这些状况都是ok的。了解现有实现全部知识的同时，再结合新需求考虑，就能简单地完成重写工做。