在接触任何一个新鲜事物初期时，你一定有必要了解它，知道它能给你带来什么、有哪些优势、哪些弊端，最终要搞明白它是否合适你，再决定是否使用它。技术更是如此，这也就是常常所说的技术选型、架构选型，更是作为一个架构师必须衡量考虑的。在当前技术不断革新的趋势下，每天可能都有新的概念、新的体系、新的技术(框架)出现，微服务的出现，纷纷被众多技术人、公司所追捧，仿佛给传统项目的重构、新项目的研发带来了便捷、萌发了希望，但大家都真的了解它么？
在微服务架构下，各类项目也顺势崛起，作为技术人，貌似不会微服务，都有些不好意思。(调侃一下而已)
就以下两个方面，带你更好的了解微服务架构体系，明白为什么在微服务架构下各类项目的顺势崛起。
- 什么是微服务
- 为什么要使用微服务
什么是微服务
微服务的概念，最早由Martin Fowler与James Lewis于2014年共同提出，在近几年才走入大家的视线，引起关注。首先，我们看一下Martin Fowlern在《Microservices》一文是如何给微服务下定义的：
如Martin所言，将单体应用拆分为一组微小的服务，每个微小的服务单独运行，服务间可通过如RESTful API这样轻量级的接口交互，这些服务以业务能力为核心，用自动化部署机制独立部署。这些服务可以用不同语言开发，用不同技术来存储数据。
以我理解来看，微服务架构的特性如下：
- 将单体应用进行解耦，按照一定方式(如：业务分类等)拆分为多个微小的服务，微服务间相互交互以完成实际业务流。
- 微服务间通信方式更轻量化，如：RESTful。
- 各微服务支持单独部署、单独运行。
- 各微服务的开发语言不限，可交叉选择不同语言。
简单来说，微服务其实是从早期的CORBA、COM+等技术，到后来的SOA、RESTful架构，是一种分布式计算思想的延续。
具体来说，把单体应用拆分为一个一个微小服务，而这些微小服务又不依赖任何服务器，使其可以通过自动化方式独立部署，每个服务可以运行在自己的进程或Docker容器中，通过轻量的通信机制，能够基于业务能力快速构建，动态扩容，实现集中化管理的系统架构。
为什么要使用微服务
伴随着互联网系统的爆发、系统的多样化以及系统分层切块的演变，系统变得越来越复杂，调用链也越来越复杂，传统单体系统已经无法再支撑这种变化，因此微服务的思想也就顺应而来，用来解决这种现状。
传统的单体系统，企业往往需要耗费几个月乃至几年，才能落地一个系统，达到上线的标准。这就给一些小公司的前进带来了瓶颈，没人敢轻易研发、重构一个新的产品，但在现在互联网日益变革的时代，不得不大胆向前尝试，力争在最短的时间内完成一个新的产品。在互联网时代常常要求一周内完成一个功能或小项目，这种不断伸缩的业务形态，不断要求缩短的开发周期，使得我们需要在系统的扩展、伸缩、减低相互影响上做出文章。
那么，怎么才能达成系统的扩张呢？在Microservice Architecture一文中提到，我们需要将服务进行拆分，拆分为前置服务和业务服务，并在前端新增SLB(Server Load Balance)，用一组相同的前置服务组成及其来提供服务。
而减低各模块、各业务的相互影响，就需要将单体系统按照模块或业务进行拆分，以此来减低其耦合性。
上面提及到问题，在微服务架构下，给出了一些完美的解决方案。
模块服务化
单体系统，团队在多人协作开发时，往往会存在因代码、设计思路等差异而造成相互影响，相互等待对方的现状，而且系统的庞大也给后期维护带来诸多不便。而微服务最突出的一个特性“解耦”，恰恰解决了这种问题，让系统更加轻量化，便于多人协同开发而互不依赖。
独立部署，灵活扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立服务（例如：用户服务，文件服务等）为单位进行部署。用下图能够更好的体现：
左边是单体架构的集群，右边是微服务集群 。
各个服务都是独立部署，可以根据各自服务的特点进行适当调整，即：根据服务的吞吐量、压力等不同的指标，分别给出不同的部署方案(部署策略)，使得资源更加充分合理的使用。这种灵活部署只有微服务架构才能实现。
资源的有效隔离
这是微服务设计的原则之一，就是每一个微服务拥有自己独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。
如果采用Docker部署，则每一个微服务实例在Docker容器上运行，更加完美的实现了服务器资源（内存、CPU资源等）的有效隔离 。
多语言，多选择
在微服务架构下，因为有了模板服务化，各模块互不依赖的特点，对开发语言的选择就没有统一的要求，完全可以根据企业技术人员情况，不同模块的特点来选择不同的开发语言，让开发变得更加多样化。
团队组织架构的灵活
微服务架构设计的思想，改变了原有的企业研发团队的组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。
而微服务架构的设计思想对团队的划分有了一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。这种团队组织架构，也更好的协同来完成一个系统。
当然，上述这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。
组件/框架多样化、成熟化
伴随着微服务出现，不断膨胀，各类技术组件、框架应用而生，为我们的开发降低了成本，加快了项目的开发周期。这些组件/框架纷纷落地投产，变得更加的稳定成熟。Spring Cloud家族就是一类典型的代表，后续文章将在详细介绍在微服务中的技术选型。
正因为微服务上述这些特性，使得在微服务的影响下，各类项目顺势崛起，为各类中小型软件公司带来了希望。
参考：
1.https://microservices.io/index.html
2.https://www.cnblogs.com/beanbag/p/9911452.html
欢迎微信扫码下面二维码，关注微信公众号【程序猿技术大咖】，进行更多交流学习！