微服务架构下的核心话题 (一)：微服务架构下各类项目的顺势崛起

一、前言 



     作者接触微服务也好久时间了，从零开始构建公司产品的微服务化，目前逐步成型稳定。计划在接下来的时间里，把微服务架构下项目的实践，分门别类的总结汇总，围绕“微服务架构下的核心话题”，与大家分享，希望能够给大家在微服务中带来帮助，助力你更好的了解它，避免走不必要的弯路。



     在接触任何一个新鲜事物初期时，你一定有必要了解它，知道它能给你带来什么、有哪些优势、哪些弊端，最终要搞明白它是否合适你，再决定是否使用它。技术更是如此，这也就是常常所说的技术选型、架构选型，更是作为一个架构师必须衡量考虑的。在当前技术不断革新的趋势下，每天可能都有新的概念、新的体系、新的技术(框架)出现，微服务的出现，纷纷被众多技术人、公司所追捧，仿佛给传统项目的重构、新项目的研发带来了便捷、萌发了希望，但大家都真的了解它么？



   在微服务架构下，各类项目也顺势崛起，作为技术人，貌似不会微服务，都有些不好意思。(调侃一下而已)



   就以下两个方面，带你更好的了解微服务架构体系，明白为什么在微服务架构下各类项目的顺势崛起。



• 什么是微服务

• 为什么要使用微服务



二、什么是微服务



     微服务的概念，最早由Martin Fowler与James Lewis于2014年共同提出，在近几年才走入大家的视线，引起关注。首先，我们看一下Martin Fowlern在《Microservices》一文是如何给微服务下定义的：





In short, the microservice architectural style  is an approach todeveloping a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API. These services are built around business capabilities andindependently deployable by fully automated deployment machinery. There is abare minimum of centralized management of these services, which may be writtenin different programming languages and use different data storage technologies.



     如Martin所言，将单体应用拆分为一组微小的服务，每个微小的服务单独运行，服务间可通过如RESTful API这样轻量级的接口交互，这些服务以业务能力为核心，用自动化部署机制独立部署。这些服务可以用不同语言开发，用不同技术来存储数据。



   以我理解来看，微服务架构的特性如下：



• 将单体应用进行解耦，按照一定方式(如：业务分类等)拆分为多个微小的服务，微服务间相互交互以完成实际业务流。

• 微服务间通信方式更轻量化，如：RESTful。

• 各微服务支持单独部署、单独运行。

• 各微服务的开发语言不限，可交叉选择不同语言。



    简单来说，微服务其实是从早期的CORBA、COM+等技术，到后来的SOA、RESTful架构，是一种分布式计算思想的延续。



    具体来说，把单体应用拆分为一个一个微小服务，而这些微小服务又不依赖任何服务器，使其可以通过自动化方式独立部署，每个服务可以运行在自己的进程或Docker容器中，通过轻量的通信机制，能够基于业务能力快速构建，动态扩容，实现集中化管理的系统架构。



三、为什么要使用微服务



       伴随着互联网系统的爆发、系统的多样化以及系统分层切块的演变，系统变得越来越复杂，调用链也越来越复杂，传统单体系统已经无法再支撑这种变化，因此微服务的思想也就顺应而来，用来解决这种现状。



      传统的单体系统，企业往往需要耗费几个月乃至几年，才能落地一个系统，达到上线的标准。这就给一些小公司的前进带来了瓶颈，没人敢轻易研发、重构一个新的产品，但在现在互联网日益变革的时代，不得不大胆向前尝试，力争在最短的时间内完成一个新的产品。在互联网时代常常要求一周内完成一个功能或小项目，这种不断伸缩的业务形态，不断要求缩短的开发周期，使得我们需要在系统的扩展、伸缩、减低相互影响上做出文章。



    那么，怎么才能达成系统的扩张呢？在Microservice Architecture一文中提到，我们需要将服务进行拆分，拆分为前置服务和业务服务，并在前端新增SLB(Server Load Balance)，用一组相同的前置服务组成及其来提供服务。



    而减低各模块、各业务的相互影响，就需要将单体系统按照模块或业务进行拆分，以此来减低其耦合性。



    上面提及到问题，在微服务架构下，给出了一些完美的解决方案。



1.模块服务化



      单体系统，团队在多人协作开发时，往往会存在因代码、设计思路等差异而造成相互影响，相互等待对方的现状，而且系统的庞大也给后期维护带来诸多不便。而微服务最突出的一个特性“解耦”，恰恰解决了这种问题，让系统更加轻量化，便于多人协同开发而互不依赖。



2.独立部署，灵活扩展



    传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立服务（例如：用户服务，文件服务等）为单位进行部署。用下图能够更好的体现：





      左边是单体架构的集群，右边是微服务集群 。



      各个服务都是独立部署，可以根据各自服务的特点进行适当调整，即：根据服务的吞吐量、压力等不同的指标，分别给出不同的部署方案(部署策略)，使得资源更加充分合理的使用。这种灵活部署只有微服务架构才能实现。



3.资源的有效隔离



      这是微服务设计的原则之一，就是每一个微服务拥有自己独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。



     如果采用Docker部署，则每一个微服务实例在Docker容器上运行，更加完美的实现了服务器资源（内存、CPU资源等）的有效隔离 。



4.多语言，多选择



     在微服务架构下，因为有了模板服务化，各模块互不依赖的特点，对开发语言的选择就没有统一的要求，完全可以根据企业技术人员情况，不同模块的特点来选择不同的开发语言，让开发变得更加多样化。



5.团队组织架构的灵活



     微服务架构设计的思想，改变了原有的企业研发团队的组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。





      而微服务架构的设计思想对团队的划分有了一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。这种团队组织架构，也更好的协同来完成一个系统。



   当然，上述这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。



6.组件/框架多样化、成熟化



     伴随着微服务出现，不断膨胀，各类技术组件、框架应用而生，为我们的开发降低了成本，加快了项目的开发周期。这些组件/框架纷纷落地投产，变得更加的稳定成熟。Spring Cloud家族就是一类典型的代表，后续文章将在详细介绍在微服务中的技术选型。



     正因为微服务上述这些特性，使得在微服务的影响下，各类项目顺势崛起，为各类中小型软件公司带来了希望。



参考：

1.https://microservices.io/index.html

2.https://www.cnblogs.com/beanbag/p/9911452.html