标签：
微服务架构（Microservices ），是一个新的概念，但不是一项新的技术。看一下那些大型互联网企业，早在十年前就在使用类似架构，再看一下游戏行业，大型网游的架构从一开始就是采用类似的架构，这起码要追溯到二十年前。
微服务架构和传统SOA架构最大的区别是个性化（非通用化）。传统SOA所采用的方式跟它的起源有关系，传统SOA是由IBM等大公司倡导的，它们把某些通用的企业应用封装成某类服务，然后卖给企业，企业就可以使用该服务，并且企业可以购买不同的服务进行组合。而互联网公司就不同了，它们从开始就是自己研发，并且各个应用运用团队和运营目标都不同，就导致开发团队也不同，最后如果要采用面向服务就有了类似于微服务的架构。
以大型电子商务网站为例，查询功能可能是一个团队开发的，于是就成为一个独立的服务，订单模块可能也是一个专业团队优化的，于是又是一个服务，组合起来就是类似于微服务的架构。
和传统SOA一样，微服务最大的特点首先也是面向服务。模块与模块之间使用RPC调用方式，而不是进程内调用方式。
对于RPC调用和进程内调用，前者除了增加开发量，还增加了部署的工作量，比如：
你如果有100台机器，部署一个单一应用只需要部署一百次。
但你要部署5个微服组成的应用，就需要部署5x100=500次，这中间还牵扯到联调工作及复杂的服务监控。
孢子框架核心是“轻量级”，旨在将服务架构的开发和部署降到中小企业可以接受的程度，从而实现渐进式、模块式开发。否则的话，企业发展到一定程度所有系统都需要重做，现在很多企业也是这么做的，浪费了大量的财力不说，甚至无法实现企业经营目标。这里还关系到中国软件开发的一些黑幕，对于一般中小企业来讲，通常不设架构师之类的岗位，而是由项目经理主管技术和项目进度，项目经理往往重点关注目前的业务需求，中小企业的老板往往也是只看重目前需求的实现，于是就有了不经详细规划的技术方案和急于求成的项目落地。既然落地了，往后就是增加功能和修修补补，项目越做越大，数据越积越多，效率越来越低。等到项目要垮掉的那天，项目歇菜，而项目经理可以跳槽，继续拿高薪。笔者遇到很多这样的项目。
孢子框架“轻量级”的实现主要依赖于“接口访问层”，业务前端访问“接口访问层”获得服务。接口访问层调用服务层接口执行操作，调用服务层的方式（服务层发布成各种接口）可以有很多，由接口访问层统一封装，提供给前端调用的是统一方式，如下图：
这样以来，小并发量的应用一开始可以以API调用或者Rest接口调用，随着应用用户量的增加和并发量的增加，可以将服务层发布成dubbo接口或者netty接口等，发布后前端应用不需要更改任何代码。
另外孢子框架的“轻量级”还体现在轻量级的渐进式“数据库分库”模块，孢子框架中的数据库分库模块，可以实现数据库垂直和水平分库，并且自始至终支持事务。最重要的特点是渐进式使用，即垂直分库和水平分库采用同一种使用/调用方式。对于应用在并发量小的阶段，主要使用垂直分库，而到了百万级并发以上才可能使用水平分库。所以要支持渐进式开发，不浪费生产力的情况下，就必须使用同一种编成技术来实现这两种分库，笔者目前还没发现这种第三方分库组件，因此自己封装了一个，是基于spring框架，所需代码也并不多。
标签：
原文地址：http://www.cnblogs.com/skyblog/p/4861012.html
