作者
无精疯
来源
大数据肌肉猿（ID:BigData-BigMuscle）
看上图，当一条猎狗抓一只兔子的时候是不是很轻松，毕竟兔子的体型比狗小的多。
但当一条猎狗去捕捉野猪呢，那我们就可以等着吃狗肉了。野猪的力量和体型不比狗小，对于狗来说，野猪就是大数据。
一条狗治不了那我就安排多条，一条负责咬耳朵，一条咬喉咙，一只条咬肚子，分工明确，成功把野猪拿下。
为了捕捉到野猪我可以有两个选择，一个是养头猎豹，一个是养三条土狗。养猎豹的话是不可能的，属于保护动物，就算可以养，成本也高。养三条土狗的成本远远比养一头猎豹的低的多，但能达到的目的是一样的。这三条土狗就组成一个简单的分布式系统，每条狗都相当于一个微服务，不同的分工，协力合作。
微服务没有一个精确的定义，可以说这是一种软件架构风格，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用通过API相互通讯，而实现方法也多种多样，每个公司使用微服务的出发点也不尽相同。但是微服务却有几个重要的共同特点：
1.小而单一(smallandsingleresposibility)，并且专注于做一件事情，只负责一个系统下的某一个功能
例如例子中的猎狗，在捕杀野猪时分工明确，全身心的做自己该做的事。
在初步划分模块的时候，通常公司可以按照自己的业务领域来分块服务，一个典型的例子就是垂直电商系统一般可以分为：
用户模块服务CustomerService,、产品模块服务ProductService、订单模块服务OrderService、支付模块服务PaymentService和运送模块服务ShippingService。
每一个服务只负责一个领域模型中所需要完成的任务。这样轻松实现整个微服务系统的松耦合和较高的维护能力。
2.独立部署(independentlydeployable)，升级，扩展或者替换
当我们发现咬野猪的生殖器官比耳朵更致命时，我们就可以训练野狗这个技能，方便下次以更快速度进行捕杀，这就是升级。
要是准备去捕杀一只野猪王，它体型比平时的野猪都大，而且凶。这时候三条猎狗是不够的，我们可以多叫上几条猎狗，这就是扩展。
当一条土狗阵亡了，我可以比较快速地去再养一只，让它尽快地参与战斗，这就是替换。
在此我们可以对比一下单体应用(monolithicapplication)。譬如上文中提到的垂直电商系统，在单体应用下，所有这些模块都是打包在同一个war，或者ear文件下面，部署到一个应用服务器上面，这个应用服务器可以Web应用服务器，譬如Tomcat，或者是J2EE应用服务器，譬如WebLogic或者是Jboss。
通常在这样架构下，当我们需要替换，升级，或者一个简单的修改某一个模块，譬如支付模块的话，我们需要怎么做？修改支付模块代码，编译整个项目，重新打包成一个war，ear文件，然后替换整个应用系统。
即使我们修改的模块和其他模块没有任何关系，但是，我们必须一起替换。这就增加了我们日常的工作量和风险，譬如测试方便，除了做单元测试，我们还需要做一个集成测试，来保持我们其他模块一样工作。
如果一个架构不是很好的系统，软件模块之间没实现松耦合，那么修改一个模块，很有可能导致另外一个模块的不工作。
当你是一个新人，加入一个开发组，teamleader告诉你，把支付模块一个bug修了，你废了九牛二虎之力，很开心的修完了那个bug，通过单元测试，提交了代码，过了一会一封邮件过来，jenkins上面出错了，某一个和支付模块完全不相关的用户管理模块出错了。是谁的错，不是你的错，可能是架构师没有架构好软件，但是通常情况下，你得负责。
而微服务的独立部署能力就是为了避免这样类似的问题再出现，通常一个微服务是领域驱动设计下完成的，各模块之间有非常清楚明晰的边界。
那么有人会说，那怎么从一个单体应用，转换成一个成功，松耦合，易于升级和扩展的微服务架构的。这有一个非常有趣的话题，包括很多方面的考虑，从领域驱动设计，到技术选择和实现，到怎么一步一步分解一个巨大而复杂的单体应用，到一个个微服务，以及各个微服务之间的通信选择，毕竟当你拥有个微服务的时候，微服务之间的通信已经不是简单的进程内呼叫了，而是通过网络协议来实现的，稳定性和性能都会有影响。
3.轻量级通信协议(lightweight