SpringCloud：微服务概念
一、单体架构的问题
微服务为什么会出现？在学习Springboot的时候知道Springboot极大的简化了我们的开发，我们可以快速的进行业务开发，Springboot单体应用在项目的开发初期能够满足我们需求，这种单体架构优点非常的明显：
容易测试：本地就可以起完整的系统，不需要外部依赖。
容易开发：我们只需引入依赖，选择框架便可快速开发。
易于部署：单体架构部署也较简单，直接打包即可。
易于水平伸缩：这里的收缩时指当我们需要多个服务器时也比较方便
在项目刚开始的时候我们可以快速的开发，一个长寿的项目，需求不断增加，原先的模块也再不断优化，这个时候单体架构的缺点开始显现：
代码膨胀，难以维护：代码越来越多，开发人员也就越来越多，一旦出现bug，定位、修复成本很高，而且人员太多，代码都放在一起，容易引起冲突，且由于业务集中在一起，业务复杂，很难全局把握，改一个bug可能会再多出两个bug。
构建、部署成本大：项目太大，构建和部署就会非常慢，效率低下。
上手困难：互联网企业人员更迭快，代码过于集中，导致业务非常复杂，新人想要上手变得非常困难。
技术创新困难：代码过于集中，我们很难使用到新技术，因为改动实在太大，容易出现问题。
可扩展性差：这里的可扩展性是指因为项目都必须部署在一台服务器中，那项目所要的资源会越来越大，这样我们只能扩展硬件（集群可以分散压力，但是单个应用所要的资源还是不能少的）。
二、微服务出现
微服务的出现就是为了解决这些问题，看看是如何解决的，微服务将系统拆分成一个个小服务（一般是按照模块进行拆分，比如用户服务、支付服务、订单服务、出入库服务等），那么即使业务量增加，我们也可以通过新增服务的形式来解决，这样代码就不会膨胀，构建、部署也不是问题。
由于服务不在一个框架中，那么我们可以很方便的对某一个服务进行技术创新，对一个服务的进行技术升级改动不会太大，而当我们有新技术产生时，我们就可以也可以应用到新服务中。
微服务并没有明确的定义，下面是一种比较通用的理解：
使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化方式部署。
通过定义我们可以知道微服务的特征：
微服务是由一系列的小服务共同组成的。
每个微服务都有自己独立的进程。
每个服务都是独立的业务开发，单一原则
每个服务都能独立的部署（一般部署在容器中）。
微服务之间通过轻量级通信机制进行通信
分布式的管理。
三、微服务架构图
讲到这里，对微服务的概念应该有了一定的了解，下面画的一个比较简单的微服务架构图
图中可以看出每个微服务都有自己独立的数据库，每个服务都会暴露自己的REST API 给外部调用，服务之间会存在互相调用关系，而每个服务都有可能被客户端直接调用，另外我们看到还有一个API Gateway,这是统一个服务接口，它通常可以有以下作用：
1. 提供统一服务入口，让微服务对前台透明
2. 聚合后台的服务，节省流量，提升性能
3. 提供安全，过滤，流控等API管理功能
五、技术点
要实现微服务，我们需要解决以下几个技术点：
客户端访问服务：这个上面架构图中已经给出，使用API Gateway。
服务通信：服务与服务之间的通信有两种方式，同步与异步：
同步通信中又分为两种：Http与RPC，http访问很好理解，相信一般的系统也会调用外部的一些服务，这些基本都是使用http,因为http可以跨语言，跨客户端，相对使用较广，如http Client ,而RPC也有自己的优点，首先是效率更高，更安全可控，特别是内部服务互相调用时，用统一的RPC框架，服务的侵入性更低，调用服务甚至就像调用自己的服务一样简单,如dubbo（注：dubbo只能使用java语言）。
异步通信是通过消息队列来实现，异步通信的好处是可以降低服务之间的耦合，有削峰的好处，而且使用消息队列可以方便的实现数据的最终一致性。
服务治理：为了服务的高可用，微服务一般都有多个拷贝，做负载均衡，而这个时候就必须知道服务的状态，一个服务随时有可能下线，下线之后后续有可能重新启动，这些都需要我们一个服务治理功能，也即是服务的注册与发现。
产品服务启动了三个，他们都会去注册中心进行注册，注册成功后，会通过心跳包告诉注册中心是否在线或者下线，而订单服务要去调用产品服务，会先去注册中心进行查询，查询出相应的地址然后再去调用产品服务。
服务崩溃处理：在运行期间会出现服务崩溃的情况，比如网络原因，阻塞原因，这个时候服务并不是下线，还是能够被找到，我们必须妥善要进行处理，否则可能会导致整个系统的崩溃，处理的方式有：
重试机制
熔断机制
降级机制
限流机制
六、解决方案
以上都是微服务的一些概念，既然有天上飞的概念，就有落地的实现，现在主流的微服务架构有两套解决方案：Dubbo+Zookeeper与SpringCloud。
我司现在两种方案都在用，总体来说两种方案都可以很方便的进行微服务开发，其中的区别在于SpringCloud组件多，功能完备，全家桶式，基本微服务中会遇到的问题都有相应的解决方案，在通信方面SpringCloud使用的是http。
而Dubbo+Zookeeper使用的是RPC，组件较少，功能非完备（但是我们可以自己去找相应的解决方案），并且现在交由Apache进行孵化，后面应该会实现功能的完备。
RPC 也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。
当我们的服务时一个对内服务时，我们可以使用Dubbo+Zookeeper，比如一些公用的服务，这些一般是提供给内部
剩下的就不会给大家一展出来了，以上资料按照一下操作即可获得
——将文章进行转发和评论，关注公众号【Java烤猪皮】，关注后继续后台回复领取口令“ 666 ”即可免费领文章取中所提供的资料。
往期精品推荐
腾讯、阿里、滴滴后台试题汇集总结 — （含答案）
面试：史上最全多线程序面试题！
最新阿里内推Java后端试题
JVM难学？那是因为你没有真正看完整这篇文章
—结束—
关注作者微信公众号 — 《JAVA烤猪皮》
了解了更多java后端架构知识以及最新面试宝典
看完本文记得给作者点赞+在看哦~~~大家的支持，是作者来源不断出文的动力~
评论