现在微服务、SOA、RESTful API设计等在各大公司很流行。微服务(micro services)这个概念不是新概念，很多公司已经在实践了，例如亚马逊、Google、FaceBook，Alibaba。微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。 Micro这个词意味着每个服务都应该足够小，但是，这里的小不能用代码量来比较，而应该是从业务逻辑上比较——符合SRP原则的才叫微服务。但是微服务和SOA之间有什么差异呢？
一.简要介绍
微服务其实就是随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通过化程度发展，就成了所谓的微服务了。以这种说法做为根据，SOA与微服务的区别在于如下几个方面：
- 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；
- 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
- 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；
二.为什么要用微服务呢？
技术和架构都是为业务而生，SOA和微服务也是因为业务发展而出现。出现SOA和微服务框架与业务的发展、平台的壮大密不可分，下面借用dubbo的网站架构发展图和说明：
- 单一应用架构
- 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
- 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
- 垂直应用架构
- 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
- 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
- 分布式服务架构
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
- 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
- 流动计算架构
- 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
- 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
平台随着业务的发展从 All in One 环境就可以满足业务需求（以Java来说，可能只是一两个war包就解决了）；发展到需要拆分多个应用，并且采用MVC的方式分离前后端，加快开发效率；在发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，我觉得就可以将之理解为一个微服务了。
理想中的微服务架构
没有什么东西是完美的，网站架构也是这样的，只有「比之前好一点」的架构或「目前最好的实现方式」，不存在理想中的架构，那么理想中微服务架构应该是怎么样的呢，我觉得至少应该有如下几个特点：
- 能支持当前业务需求，当然这只是最最基本的条件；
- 每个微服务都要去中心化，不存在单点故障；
- 每个微服务都要实现高可用、高负载，不会因为一个服务不可用而影响了整套业务流；
- 每个微服务都要高度通用化，即多种终端都可调用，不分语言和平台；
- 服务部署或升级简单，不会消耗大量人力并且部署过程不易出现人为错误；
- 微服务具有快速注册与自动发现功能（例如dubbo框架）
当然，这只是其中能想到的几点，实际环境中用到的微服务框架有可能会根据实际业务需求优化出更加个性化的功能，也可能有些功能是不需要的。还是那句话，架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构，才是好的微服务架构。
三.微服务架构的优点与缺点
1. 优点
- 每个服务足够内聚，足够小，代码容易理解、开发效率提高
- 服务之间可以独立部署，微服务架构让持续部署成为可能;
- 每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上;
- 容易扩大开发团队，可以针对每个服务(service)组件开发团队;
- 提高容错性(fault isolation)，一个服务的内存泄露并不会让整个系统瘫痪;
- 系统不会被长期限制在某个技术栈上。
2. 缺点
《人月神话》中讲到：没有银弹，意思是只靠一把锤子是盖不起摩天大楼的，要根据业务场景选择设计思路和实现工具。我们看下为了换回上面提到的好处，我们付出(trade)了什么?
- 开发人员要处理分布式系统的复杂性;开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难;涉及多个服务直接的自动化测试也具备相当的挑战性;
- 服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹(PS：现在docker的出现适合解决这个问题)
- 应用微服务架构的时机如何把握?对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。
本文转自 念槐聚 博客园博客，原文链接：http://www.cnblogs.com/haochuang/p/6689109.html，如需转载请自行联系原作者
