作者简介

　　孙杰，51CTO博客专家博主

　　孙杰，拥有超十二载IT领域工作经验，先后在知名外企、电商平台和国企能源行业的数据中心从事IT系统架构搭建、云计算、大数据架构部署以及运维等工作。热爱技术喜欢分享，崇尚大道至简。在若干大中型项目的建设和运维中，积累了丰富的系统运维、架构设计、平台优化等经验。在博客平台发布了大量IT技术和生活文章，并成为51CTO平台上的专家博主。

　　近几年，随着云(如阿里云)计算技术的进步和服务的增长，微服务越来越成为在博客、媒体讨论组和会议演讲中出现的热门话题，被更多的人重点关注。正如本文作者 51CTO博客专家孙杰在文中提到的，尽管微服务架构存在着许多争论，但是这并没有影响它正在为敏捷部署及复杂企业应用实施提供着巨大的帮助的事实。究竟我们为何需要微服务架构?与传统SOA相比，微服务架构有哪些优势?在使用微服务架构的时候，我们又将面临哪些挑战?

　　怎样理解微服务

　　微服务这一概念出现于2012年，是因软件作者Martin Fowler而流行，围绕业务、自动化部署、终端智能及语言和数据的分散控制有一些常见的新特性。微服务也是一项在云中部署应用和服务的新技术。随着云计算技术的进步和服务的增长，微服务架构越来越多的受到了人们的关注。尽管也存在着许多不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供着巨大的帮助。

　　通常我们的开发也是模块化设计逻辑，程序完成后会打包并部署为一个个具体的应用。每个具体的格式依赖于相应的应用语言和框架。例如，Java应用通常会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，同样，Rails和Node.js会被打包成层级目录。这种应用开发风格很常见，也非常易于调试，只需简单运行此应用，用些工具链接UI就可以完成端到端测试。打包好的应用拷贝到服务器(如阿里云服务器)端，通过在负载均衡器后端运行多个拷贝即可轻松实现应用扩展。在早期这类应用运行的都非常好，但是一个简单的应用会随着时间推移逐渐变大。几年后，这个小而简单的应用会变成了一个巨大的怪物。一旦你的应用变成一个庞大而又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能将变的十分困难，并且很耗时。

　　当一个应用越大，启动时间就会越长。那么大部分时间就要在等待中渡过，生产效率会受到极大影响。另外，一个应用在不同模块发生资源冲突的时候，扩展将会十分困难。应用的另外一个问题是可靠性。当所有模块都运行在一个进程中，任何一个模块中的一个bug，如内存泄露，将会有可能弄垮整个进程。除此之外，由于所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。若采用微服务处理结构模式则可很好的解决上述问题。微服务架构的思想不是开发一个复杂巨大的应用，而是将应用分解为若干小的、互相连接的微服务。

　　六大优势

　　微服务架构相对于传统的SOA，优势也很明显：

　　1.容错：当某一组建发生故障的时候，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

　　2.复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。因为体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

　　3.功能特定：一个微服务一般完成某个特定的功能，比如消息管理、客户管理等等。每一个微服务都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。

　　4.独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

　　5.扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

　　6.技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。

　　三大挑战

　　1.分区的数据库架构：另外一个关于微服务的挑战来自于分区的数据库架构。在商业交易系统中同时给多个业务分主体更新消息很普遍。这种交易对于单个应用来说很容易，因为只有一个数据库。而在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

　　2.固有的复杂性：微服务架构有很多优点，当然也有其不足。比如微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。

　　3.波及多个服务：最后一个问题在于，微服务架构模式应用的改变将会波及多个服务。如假设你在完成一个项目案例，需修改服务A、B、C，而A依赖B，B依赖C。在单个应用中，你只需改变相关模块，整合变化，部署就好了。相比之下，微服务架构模式就需考虑相关改变对不同服务的影响。比如，你需更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

　　使用微服务构建适合云的新型应用是很有意义的，因为它让你既利用了横向扩展架构，也利用了纵向扩展架构，还额外得到API的组合，且在整个业务中可重复利用。可能在每一分钟都在交付新服务，这样你就会拥有一个敏捷的且即时响应的应用程序平台，当然这一平台一直在不断改进中，微服务架构也在前进着。

　　主要周边技术

　　微服务与分布式

　　云VM

　　DOCKER容器

　　微服务架构与SOA

　　微服务与数据一致性

　　微服务与数据库微服务层面如何提供缓存、权限控制、API统计和监控

　　微服务与自动化部署

　　微服务与PAAS

　　微服务与Mesos或者Kubernetes