百度百科中，可看出，“微服务”并不是一种新的技术，应该说是一种进阶的架构体系。
- 微：著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。
- 服务：一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
发展过程：单体架构 - > SOA -> 微服务
单体架构
1.复杂性逐渐变高
- 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
2.技术债务逐渐上升
- 公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
3.部署速度逐渐变慢
- 这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。
4.阻碍技术创新
- 比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。
SOA架构
webservice是SOA的一种实现方式，强调的是服务与服务之间的调用。
随着对业务系统进行垂直化改造之后，以业务功能维度拆分出来多个子系统，而在各个子系统中，会存在比较多的共享业务，比如用户信息查询，在支付业务中会涉及到、在首页中也会涉及到。那么势必会造成重复开发产生非常多的冗余代码。那么这个时候就引入了服务化改造思想，也就是SOA。
把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。这些被拆分出来的共享服务相对来说是比较独立，并且可重用。比如用户管理服务，包含用户注册、用户查询等功能。比如单点登录服务；
SOA的核心目标就是通过服务的流程化来实现业务的灵活性，形成一些共享的基础服务。这些被拆分出来的共享服务相对来说是比较独立，并且可重用。比如用户管理服务，包含用户注册、用户查询等功能。比如单点登录服务。
SOA面向服务架构，从语义上说，它于面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。所以在SOA中，服务是最核心的抽象手段，业务被划分为一些粗粒度的业务服务和业务流程，重复代码进行了抽取,提高了开发效率,提高了系统的可维护性，但系统与服务的界限模糊的,不利于设计。
微服务架构
1.易于开发和维护
- 一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
2.单个微服务启动较快
- 单个微服务代码量较少， 所以启动会比较快。
3.局部修改容易部署
- 单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
4.技术栈不受限
- 在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。
5.运维要求较高
- 更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。
6.分布式固有的复杂性
- 使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
7.接口调整成本高
- 微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
东拼西凑出的一篇文章，无法准确标注来源，原创谅解。
