微服务架构总结

微服务是什么？

“微服务”一词源于Martin Fowler的名为Microservices的博文，可以在他的官方博客上找到：http://martinfowler.com/articles/microservices.html。 简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

微服务架构提倡将原本独立的单体应用，拆分成多个小型服务。这些小型服务各自独立运行，服务与服务间的通信采用轻量级通信机制（一般是基于HTTP协议的RESTful API），达到互相协调、互相配合的目的。被拆分后的服务都围绕着具体的业务进行构建，每个服务都能独立地进行开发、部署、扩展。由于相互独立，且采用轻量级通信机制，各个小型服务也能够使用不同的语言开发，也可以使用不同的数据存储技术。

左图为单体应用，右图为微服务架构。

微服务能解决哪些问题？

服务解耦

单体应用由于面对的业务需求更为宽泛，不断扩大的需求会使得单体应用变得越来越臃肿。单体应用的问题就逐渐凸显出来，由于单体系统部署在一个进程内，往往我们修改了一个很小的功能，为了部署上线会影响其他功能的运行。并且，单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，对于资源的利用又互相影响，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。所以，单体系统在初期虽然可以非常方便地进行开发和使用，但是随着系统的发展，维护成本会变得越来越大，且难以控制。

部署

单体服务部署的问题是，如果业务量巨大，但是值修改一个很小很小的模块就需要整体进行部署。影响的面积大，不够灵活。
而拆分后的微服务可以按需部署，假如商城系统只修改的订单模块，那么只需要部署订单服务即可。

集群负载/调配

对高频访问和资源需求高的服务投入更多的资源，比如增加服务器、数据库、带宽等资源的配置。对于低频访问和资源需求相对低的服务则不需要投入过多的资源。实现最优的资源利用，提升资源的利用率，并提升系统的伸缩性。

快速迭代 + 灵活

未拆分时，在巨无霸单体项目中的开发、提交代码、回归测试都非常复杂。数不尽的代码分支，数不尽的代码冲突，还有耗时耗力的回归测试，都会让人心力交瘁。独立开发与独立部署的微服务，可以更加快速地进行功能迭代。

服务之间的耦合低，甚至可以随时加入一个新的服务或者剔除过时的服务，灵活度提升了很多。即使某个功能出现问题，只需要针对性的修改和发版即可，不会像未拆分之前一样“牵一发而动全身”。开发和修改都变得更加灵活，不会出现“要等另一个开发团队先提交代码自己才能提交代码”、“不同开发分支上所需的数据库结构不同”、“由于不同分支下的代码合并冲突导致需要更多的回归测试和代码修改”等等让人哭笑不得的事情。

技术选型灵活

这一点在微服务架构的定义中已经讲明了，单个服务可以结合具体的业务和团队的特点，选择合适的编程语言和技术栈进行实现。

微服务存在的挑战

• 运维的新挑战：在微服务架构中，运维人员需要维护的进程数量会大大增加。有条不紊地将这些进程编排和组织起来不是一件容易的事，传统的运维人员往往很难适应这样的改变。我们需要运维人员有更多的技能来应对这样的挑战，运维过程需要更多的自动化，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。
• 接口的一致性：虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理，或是严格地遵循开闭原则。
• 分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等。
• 落地一个微服务架构项目比较复杂
  要实施和上线一个微服务架构的项目，复杂度很高，工作量还是很大，要考虑和解决的问题有很多。微服务架构实施前的技术选型、微服务组件的搭建和底层支撑、项目拆分时的边界和具体落地的细则、微服务项目的开发和上线、后期的维护等等具体的工作都摆在面前，需要一个一个的处理。在落地微服务架构的项目时不仅仅是编码，还包括微服务架构的搭建和底层支撑，这件事更像是“大兵团作战”，不是一个五人突击队就能够完成的任务。
• 服务依赖和调用链路更复杂
• 分布式事务问题

微服务成熟的解决方案

• 服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX、Netflix的Eureka、Apache的Consul等。
• 分布式配置管理：百度的Disconf、Netflix的Archaius、360的QConf、Spring Cloud的Config、淘宝的Diamond等。
• 批量任务：当当网的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等。
• 服务跟踪：京东的Hydra、Spring Cloud的Sleuth、Twitter的Zipkin等。

微服务的九大特性

• 服务组件化
• 按业务组织团队
• 做产品的态度
• 只能端点与哑管道
• 去中心化治理
  不是每一个问题都是钉子，不是每一个解决方案都是锤子。
• 去中心化管理数据
  在去中心化过程中，我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（如把日志信息存储到MongoDB中或把用户登录信息存储到Redis中）。
• 基础设施自动化
• 自动化测试
• 自动化部署
• 容错设计
• 演进式设计
  架构师都会以演进的方式进行系统的构建。在初期，以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。