初识微服务

根据项目需要，开始接触微服务的一些概念，也是第一次接触微服务的概念。

今天听公司的老司机介绍了一下微服务的概念之后，重新温习了极客学院上的一段视频。

趁热打铁整理一下视频内容，加上自己的一些感想，分享给大家。

希望能通过这篇文章，让大家了解微服务的概念，当然，最重要的是思维方式。

 

极客学院视频地址：http://www.jikexueyuan.com/course/2523.html

推荐文章：http://www.oschina.net/news/70121/microservice

 

在编写正文之前。仔细阅读了一下上面那篇推荐文章，里面有几句话个人感觉很是有理，特此留念。

• 技术不是问题，意识比工具重要
• 为产品或项目赋予生命
• 微服务对我们的思考更多的是思维上的

 

一、软件架构的进化

先来看一下下面这张传统的应用的架构，这里包含了下面几个部分：

• 向用户展示的UI界面
• 实际的业务逻辑部分
• 数据存储部分

刚开始的时候，我们是将所有的这些都打包在一起，并没有严格的区分（如JSP技术），

这里并没有对每一个模块单独区分，所有的应用全都是混合在一起的。

 

随着开发语言的发展，我们慢慢的把数据访问层单独独立出来，形成了如JDBC等独立组件。如下图所示：

 

接着，在构架和设计模式的帮助下给我们的应用进行了类似下面这样的分层。这样就进化成了一个多层的模式。

 

这种多层架构，将关注点分散到各个层当中，研发人员只需要关注本层当中涉及到的逻辑和模块。

在每个层次之间定义了合理的接口，每一层又可以继续细分为逻辑模块。

同时，功能模块是可重用的，比如上面的数据访问层，就可以被多个模块所共享。

 

这种多层架构的设计，在很长的一段时间之内，都是一种主流的设计方案。

尽管我们采用了这种多层架构方案来设计我们的应用，实际上在打包方式和部署方式上仍然是一单体模式的形式存在。

目前的大多数应用也确实是采用这种单体的模式，当然了，单体模式能如此长时间的存在，必然有它的道理，

单体模式的优势在于：我们有很多已经存在的外围工具来帮助我们。

 

但是，慢慢的单体模式就展现了如下所示的不足：

①、应用工程会变得又大又复杂，以至于很难使单个工程师理解你的应用，

同时，如此大的应用更加是难以修改的，更多是难以做出正确的修改，往往是牵一发动而全身。

这么"大而复杂"的应用，更是需要一个专门的团队来运维，无形中增加了资源的浪费。

②、单体模式使敏捷式开发变得举步维艰，任何改动都需要编译、测试和部署整个应用。

需要一个很长的发布周期，以及一个很慢的反馈速度。

③、启动时间长。有的应用启动时间竟然可以达到30分钟左右。

如果开发者需要频繁启动应用，那么大部分时间就只能在等地中度过了。严重影响生产效率。

④、可靠性非常差。因为所有的模块都运行在一个进程当中，任何一个模块中的Bug都有可能弄垮整个进程。

⑤、难以采用新技术新语言。整个应用需要迁就与同一套逻辑、框架或者是技术。

 

微服务正在博客、群体讨论组、会议当中获得了越来越多的关注，它主张：

一个应用由多个独立运行的微小的服务构成，每个服务只负责于一个微小的独立的功能模块。

服务之间通过轻量级的机制进行通讯（如HTTP的REST API）。

每一个服务都可以单独的构建部署，每个服务可以使用不同的语言、甚至是不同的数据库。 

如下图中右面所示部分，是一个非常典型的使用单体模式开发和微服务架构模式开发的区别。

单体模式当中，我们把所有的功能模块都放在一个整体当中，如果我们要动态扩容的时候，每一台机器都需要扩容所有模块（×）。

微服务架构当中，我们把每一个功能模块放到了一个微小的服务当中，在扩容的时候，

可以使用更小的单位来扩容，每一台机器也可以是完全不同的微服务组合（√），并不需要将所有的应用打包到一起。

 

那么，我们来重新设计一下本片文章的开始所提到的传统应用。

每个模块都可以构成一个微小的服务，彼此之间通过REST API的方式进行交互，进行数据传输。

下面这张图就形成了一个典型的以微服务架构设计的一个应用。

 

二、微服务架构的优势

1、独立性

在构建、部署、扩容、容错甚至数据管理都是单独管理的，每一个服务只负责自己负责的一部分内容。

如果其中一个服务发生改动，只需要部署发生改动的一个服务就可以了。

同样，每一个功能模块对于数据的访问量是不一样的，我们的扩容粒度可以做的更小了，可以使访问量大的服务数量最多，

避免了在单体模式下扩容时把一些不必要的模块扩容所造成的不必要的资源浪费。

在容错机制上，我们的每一个服务出现的错误只会影响单独的进程，并不会影响整个应用。这样提高了整个应用的可靠性。

在数据管理方面，每一个服务都管理自己的数据库，避免了单体模式中数据结构的变化所带来的所有功能模块受到的影响。

 

2、敏捷性

因为把每一个代码都分到了每一个微小的服务当中，所以，代码的运行速度更快，也带来了更短的反馈周期。

简化了使用方法，因为每一个微服务功能都非常单一，非常的简单，使用起来非常方便。

同时，可以非常快速的应对变化，当发生一个新的需求的时候，可以很快的应对这种需求的变化。

 

3、接受新技术

因为微服务是分散式的管理方式，开发过程中可能每一个组或者团队只负责自己的服务，

如果需要做一些技术上的调整，只需要在组内得到同意即可。

同时，每一个微服务可以使用自己独立的技术，只需要保持对其他服务提供API的接口不变就可以。

这样的架构使之非常易于接受新事物，使重构服务变的可行。

 

4、高效的团队

每一个团队只需要负责自己的功能模块，责任明晰，边界清楚。

如果团队发生重组的时候，可以围绕业务功能进行组织，非常灵活。

 

三、微服务的不足

微服务带来了上一段落中所阐述的诸多优势的同时，也同样存在很多不足。

有的时候会过度的关注服务的大小，使一些不必要的模块都拆成了服务，造成模块之间的通讯非常复杂，

当然了，过多的服务，在分布式系统中是难以构建和部署的。

另一个对微服务的挑战来自于对分区的数据库的架构，商业交易中，同时给多个业务分主体，更新消息非常普遍，

这种交易对单体模式来说非常容易（因为只有一个数据库嘛），在微服务架构当中，需要更新不同服务所使用的不同数据库，

这就给我们的数据统一带来了一定的难度。

测试一个基于微服务框架的应用也是很复杂的，在单体模式中一个REST API可以完成的测试，

在微服务架构中，需要启动相关联的所有的微服务，给测试带来了相当大的复杂性。

另外一个挑战在于"一个改变"通常会波及到多个微服务，比如修改一个案例涉及到A、B、C3个微服务，

ABC之间又存在依赖关系时，修改一个服务就需要考虑相关改变对不同服务的影响。

 

四、零碎总结

今天听了老司机对微服务架构的介绍，以及大家对微服务所提出的一些问题时，结合大数据的应用场景总结了一些个人观点。

当然了，作为小白+的我来说，这些观点不具备权威性，需要辩证的去参考。

①、一些无状态的服务更适合采用微服务架构，而像Hadoop，Storm，Spark，分布式存储等这类有状态的服务，不建议使用微服务。

②、一个大数据项目中，并不是所有的处理都需要使用为服务架构，可以摘取出一部分功能，循序渐进的进化成微服务。

③、微服务架构的技术核心是Docker，微服务的指挥系统常用Kubernetes或者Mesos。

 

就像娶媳妇一样，既然接受了她的优点，也同样需要接受她的缺点（希望这些缺点可以在技术的进化中不断解决）。

希望通过这篇博客，达到了解微服务，熟悉微服务的思维方式的目的。

 

具体微服务涉及到的技术细节（Kubernetes + Docker），不在本篇博文的技术范围。

Docker的主要目标是“Buile，Ship and Run Any App，Anywhere”，

即通过对“应用组件”的封装（Packaging）、分布（Distribution）、部署（Deployment）、运行（Running）等

生命周期的管理，达到应用组件级别的“一次封装，到处运行”。

这里的应用组件，既可以是一个Web应用，也可以是一套数据库服务，甚至是一个操作系统或编译器。

用户操作CDocker容器就像操作一个轻量级的虚拟机那样简单。

开发者们需要一种创建分布式应用程序的方式。

如果有机会，等实践之后另行总结吧。

 

--END--