微服务实践之客观认识微服务

关注嘉为科技，获取运维新知

 

01
当人们谈论微服务的时候，
他们究竟在说些什么？

 

微服务由MicroServices翻译而来，是一种软件架构风格，它以专一于单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集互相通信。

以上是维基百科对微服务的定义，专业词汇不算少，接下来咱们经过对比传统的单体架构、SOA架构来理解微服务。

 

如何理解单体架构和微服务架构？

 

打个比方，如今需求生产一辆玩具车，一种作法是设计一条工序繁多、功能强大的生产流水线，各类原材料通过该流水线的加工处理，最终直接产出一辆完整的玩具车；

 

另外一种作法是设计不少条工序简单、功能单一的流水线，分别用于生产车门、底盘、座椅、轮胎等部件，每一个部件都预留好接口，生产完部件再将它们拼装成玩具车。

 

单体架构相似前一种生产玩具车的作法，最终产品很完整，但内部结构可能很是复杂，各部件难以拆分和替换，非要替换部件的话只能修改整条生产流水线，代价大，影响范围广。

 

微服务架构相似后一种作法，将复杂的生产流水线拆分红不少功能单一的流水线，各部件的生产流程相对简单，只要合理设计好部件的接口，最终也能顺利拼装出玩具车，若是想要替换部件，只需修改生产该部件的流水线，其余流水线几乎不受影响，修改为本低，影响小，效率高。

 

因此，当人们谈论微服务的时候，其实他们谈的是如何设计“乐高积木”，以及如何将这些“乐高积木”拼装成一套软件系统。

 

02

单体架构哪里错了？

 

自软件工程面世以来，单体架构就一直存在到如今，期间曾有SOA架构出来挑战其地位，最后以失败了结，如今又轮到微服务来下战书。讲道理，单体架构存在了几十年，贡献了大量优秀软件项目，为何总有新架构来挑衅呢？

 

单体架构会将应用程序的全部功能都打包成一个独立的程序包，一个刚设计完的单体应用每每都具有一些共同点：结构清晰、依赖简单、方便开发和调试、易于部署和测试，一切完美无瑕。然而，软件项目是一个不断迭代和变化的过程，加模块、扩功能、改需求简直就是屡见不鲜，而全部的变化最终都得靠修改这个单体应用的代码来实现。

结果可想而知，就算开始时的设计再合理再完美，也会由于频繁的迭代和变动成长为一个庞然大物四不像，离当初的目标愈来愈远。

 

随着软件系统愈来愈庞大和复杂，潜藏的问题开始凸显出来——

 

代码难以维护：一个大型单体应用可能有几十人甚至几百人参与过代码开发，其内部结构的复杂度已经没有任何我的能够彻底掌握；

 

性能难以扩展：几乎没有办法对局部高频使用的功能作针对性扩展，就算只为了提升很小一部分功能的负载能力，也不得不完整地扩展整套应用，形成严重的资源浪费；

 

系统稳定性差：改一发而动全身，有时一个微不足道的小问题，却能让整个系统没法正常使用；

 

开发效率低：全部人都在同一份代码上开发，代码冲突不断，开发工做由于代码版本的同步问题而停滞不前；

 

部署耗时：应用启动消耗时间长，任何小问题均可能致使启动失败，一旦出错只能所有从新来过；

 

技术过期：单体架构的技术选型，大多在开始的时候就肯定了，若是一个工程迭代了不少年，那么几乎用不上后来出现的新技术，除非总体重构，而重构的代价是巨大的，过期的技术又吸引不了优秀开发者，进退两难。

 

因此说，单体架构小时候仍是很优秀，只是成长的过程当中承受不了各方面的变动压力，最终畸形了。若是能够不成长，单体架构依然是很好的选择，但事实证实这不太现实。

 

03

微服务和SOA有什么区别？

 

软件架构历史沿着单体架构、SOA架构、微服务架构的路径发展，若是比较这三者的差别，会发现SOA和微服务的理念其实很像，都是分布式架构，甚至微服务的不少概念都沿袭自SOA。

 

SOA即Service-Oriented Architecture，面向服务的体系架构，它也是以服务为维度来设计软件的。SOA的服务是宏观意义上的服务，或者说是功能组件，好比从ERP中抽离出一个功能相对独立的统一用户管理的小型系统，可独立部署使用，也可提供用户信息给ERP的其余模块使用。

 

虽然SOA谈的是面向服务，但它的核心组件实际上是应用，服务只是应用对外提供的一种能力，并不能独立存在。因此，SOA能够理解为面向小型应用的架构，这些小型应用能够对外输出服务能力，服务接口大多数时候采用SOAP协议（即WebService），并经过ESB组件进行通讯和管理。

SOA架构原本是为了去中心化，结果ESB却成为了事实上的中心和瓶颈，再加上重量级的SOAP协议性能不佳，最终慢慢走向没落。

 

微服务的“微”字，也许当初就是相对SOA服务而言的，实践微服务的先行者和贡献者Netflix公司，就曾将他们的架构称为“细粒度的SOA”，可见微服务和SOA一脉相承。

 

相比较SOA而言，微服务抛弃了SOAP协议，改用轻量级的HTTP RESTful API，抛弃繁琐的ESB组件，取而代之的是更加灵活轻便的API网关。微服务再也不以小型应用为单位进行服务拆分，大多数微服务可能仅仅是一堆后端接口的集合，自身都构不成一个完整的功能模块。

 

微服务的服务拆分粒度比SOA更小也更灵活，能够由少数业务关联的API组成一个服务，也能够由不少API组成一个服务，甚至能够将单独一个高负载的接口封装成微服务，这一切彻底根据业务需求、性能要求和扩展弹性来灵活设计。

 

因此，微服务是一个比SOA更轻量、更方便扩展、去中心化更完全的分布式架构。轻量级这点很关键，它使得持续部署成为了可能，微服务、DevOps、容器化几乎是同一时间流行起来的，相信这不是简单的偶然事件。

 

04 

微服务是软件架构的银弹吗？

 

布鲁克斯在30多年前的论文提出，没有任何一种单纯的技术或管理上的进步，可以保证在十年内大幅度地提升生产率、可靠性和简洁性，是为“没有银弹”。微服务的出现可否打破这魔咒呢？答案依然是“没有银弹”。

 

软件架构没有最好的，只有最合适的。支撑阿里双十一的技术架构足够强大了吧？然而它却不必定适合你，一是没有海量并发处理能力的需求，势必形成资源浪费，二是维护这样一套架构，额外需求的开发、运维人员可能比本来开发业务系统的人员还多。盲目跟风微服务，其结局也可能跟前面的例子同样，得不偿失。

 

首先，微服务的优点仍是明显的——

 

◉  复杂度可控：将本来单体应用内部的复杂度分而治之，每一个微服务只负责单一的职责，复杂度显著下降；

 

◉  独立部署，稳定性高：每一个微服务单独一个进程，单个微服务的宕机、从新部署，对整个系统而言只是局部功能的暂时不可用，其余功能依然能够正常使用，并且，微服务通常会作双节点以上的高可用，所以系统的总体稳定性是比较高的；

 

◉  扩展方便：针对负载高的微服务，能够快速地进行水平扩展，哪一个负载压力大扩哪一个，跟打地鼠游戏同样简单，弹指挥间实现服务的升降级；

 

◉  技术选型灵活：因为微服务经过标准的HTTP协议通信，对开发语言没有任何限制，所以每一个微服务均可以自由选择技术类型，互不影响，新语言、新技术，想用就用。

 

不过，微服务的缺点也很多，特别对于小型项目来讲。若是开发一个简单的CMS系统，也搬出微服务一整套架构，那就是杀鸡用牛刀，过分设计。让程序员抓狂的事情，一是产品经理变动需求，二是架构师过分设计。

 

接下来咱们细数一下微服务的缺点——

 

◉  维护难度高：虽然单个微服务的复杂度不高，但把全部微服务组合成一个完整应用的难度却不低，微服务的整体复杂度甚至高于单体架构。

一个微服务架构，不可或缺的组件包括API网关、服务注册与发现、消息机制、容错管理、负载均衡、日志收集、应用监控等等，必须把这些组件都准备完毕后，才能真正开始业务代码的开发。当某个功能报错时，整条调用链路的任何一环均可能致使这个错误，排查难度高，不像单体应用直接调试代码那么简单。

 

◉  分布式事务：微服务的设计原则之一包括数据库隔离，这就成了分布式数据库，本来一个简单事务就能解决多表写操做，如今不得不考虑CAP理论和取舍、两段式提交、事务补偿等一大堆跟业务无关的技术难题；

本来一个JOIN语句就能搞定的联表查询，如今不得不考虑API调用链、并行处理、数据缓存等等，而最终的查询性能可能还不如JOIN来得高效。

 

◉  异步消息：为了提升总体的吞吐能力和交互体验，不少时候消息队列是必须的，将接口调用的阻塞等待转化成异步回调，一个接口瞬间变俩，若是再加上分布式事务，编程复杂度直线上升。

 

◉  调试复杂：微服务架构的应用，几乎很难在开发人员的电脑上运行全部的组件和服务，这将耗费很是多的CPU和内存资源，因此只能一部分服务在本地运行，一部分服务在公共服务器上运行，调试代码的时候须要处处切换环境排错，服务器上的接口还不方便debug，效率低下。

 

◉  技术门槛高：拿Java Web项目来讲，本来开发一个单体应用，程序员只要掌握好Java开发基础、经常使用框架技术、数据库基础差很少就够了，而一旦改用微服务，什么服务注册发现、消息队列、API网关、负载均衡、分布式事务、容错处理等一系列新技术、传统技术通通都得掌握，并且写代码时还必须头脑清晰有大局观，不然很容易写出一堆Bug。

 

◉  DevOps能力：除了开发技能过关外，团队还必须具有必定的DevOps能力了，不然会花费一大部分的时间在编译出包、部署排错、集成测试这些重复又琐碎的事情上面。

 

可见，微服务不是放之四海而皆准的银弹，只有深刻理解微服务的优点和劣势，客观认识自身项目的业务和技术需求，才能作出最恰当的技术架构选择，避免为了微服务而微服务。

 

若是你已经跟微服务确认过眼神是符合实际要求的架构，那么后面的文章，咱们将开始介绍具体的微服务落地技术。