昨天为了跟00后划清界限，十八岁的照片刷屏了；今天跨年，朋友圈又刷屏了。而这背后支撑海量数据、高并发的接口调用的，就是这几年火起来的微服务。其实微服务并非新概念，而是从原来的SOA之类的概念演化而来。今天这里仅对微服务架构做初步探讨。
记得08年刚踏入程序猿这条不归路的时候，呆在一家小公司“无偿”无压力地看书自学、写写小项目，那会儿公司就在搞一个SAAS项目，得知了啥是“软件即服务”这个说法。SAAS的实现需要SOA这个方法论，SOA是“面向服务架构”的意思，通过模块化组件来实现服务的组装和复用。从SAAS到SOA，都是随着互联网的发展应运而生，SAAS是互联网运营概念，SOA是互联网架构概念。之前SOA通用的解决方法是ESB，即”企业服务总线“，是一个重量级的巨无霸，但是大象是无法跳快舞的。当面对业务层面的演化而这种架构已无法适用时，必然会出现新的解决方案。于是14年国外一个叫马丁的哥们第一个提出了微服务这个概念，然后就火遍全球了。
微服务解决的是单体架构(web网站一个war包、巨石架构)、垂直架构(MVC架构)所无法解决的问题：系统扩展带来系统资源的浪费、代码修改带来重复部署的低效率、编程语言单一导致的技术选型单一以及模块耦合度高带来业务变更响应度低。最后一个问题的极端就是，技术无法支撑业务的变更速度，这让很多互联网冠名的产品很难堪。那么马丁的微服务为何能神奇的解决以上问题呢？套用一句古话：无非就是分而治之。说白了还是解耦，架构思想中精华之所在。微服务的特点就是微，职责单一的服务，代替传统的模块化服务。比如最常用最简单的登陆验证功能，支持短信验证或图形验证，现在我们不需要你提供一个功能块给我，只需要给我一个单一的服务。我们把功能切成最细颗粒的登陆、短信验证码下发、图形验证码获取、短信验证码校验、图形验证码校验等服务。小的好处就是可以重复使用，如果我另一个功能也需要图形验证码，那么直接调用图形验证码获取接口即可，不用把代码复制过去；接口解耦、隔离，互不影响，图形验证码功能挂了，短信验证码功能还可以用，那么我的登陆功能还可以用；独立部署，我可以把这几个服务单独部署到不同的机器上，这样我改登陆功能只需要部署登陆服务，其他服务运行不受影响，而且我想加入一个使用其他语言写的服务也很简单。
微服务好处如此之多，难道就没有啥不好的地方吗？当然有的，有时候优势就是劣势。微小的服务支撑起业务的灵活编排，快速响应互联网的业务迭代，但部署的复杂度也对应增加了。原来我只要部署一个war包，现在可能是成百上千个，而且问题定位的难度也是成倍增加的，调用链越长越不好排查。这对运维人员来说可能是个噩梦，半夜随便一个服务挂了就得起来搞，想想都得失眠。微服务为了高可用，采用分布式架构，而这必然带来相应的分布式复杂性问题：如网络延时、网络分区等问题。而微服务之间的跨进程rpc调用，不可避免的增加服务响应时间，通信成本提高了，说白了就是页面变卡了，用户体验变差了。
马丁大哥给微服务下了定义，要满足他提出的4条要求才能称之微服务：1、根据业务模块划分服务种类；2、每个服务可独立部署且互相隔离；3、通过轻量级API调用服务；4、服务需要保证高可用。第一条需要从业务上明确，第二条参考第一条开发服务即可，第三条和第四条纯粹就是技术选型的问题了。现在一般微服务架构都是前后端分离，前端调后端接口获取数据后渲染到页面做展示。后端才是微服务是用武之地，根据业务不同对服务分层，每一层服务下面可以对服务分组。但是同一层服务不能交叉调用，否则就违反了各个服务的隔离性这一点，而且服务依赖也将产生依赖的复杂度。前端对后端的服务调用需要通过一个服务网关来统一处理，这个服务网关可以并发调用许多微服务来渲染一个前端页面。服务网关不能做厚做大，它仅仅是一个服务调用的关口。微服务发布时需要注册到一个服务注册中心，当服务网关来调用时通过服务注册中心查找，进行服务的发现。服务注册中心为了避免单点故障，有两个方案：一个是集群(这个基本不用说，大家都会做)，一个是本地缓存，确保服务注册中心挂掉后直接从内存中发现服务。
微服务框架目前有阿里的Dubbo，当当扩展Dubbo的Dubbox，加入了REST，Spring Cloud可自己定制功能，以上都是开源的，可以直接从网上下载源码。不开源的有阿里的HSF、华为的DSF，这个就不说了。基本上就先说到这吧，静等跨年。