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

1、前言 

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

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

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

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

• 什么是微服务
• 为何要使用微服务

 

2、什么是微服务

     微服务的概念，最先由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容器中，经过轻量的通讯机制，可以基于业务能力快速构建，动态扩容，实现集中化管理的系统架构。

 

3、为何要使用微服务

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

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

    那么，怎么才能达成系统的扩张呢？在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

 

欢迎微信扫码下面二维码，关注微信公众号【程序猿技术大咖】，进行更多交流学习！