微服务组件架构图：
这几张图啊，大同小异，讲述的都是同一件事情，微服务结构以及架构：
首先，我们了解微服务之前，有必要了解一下他的发展，存在即合理，呢么微服务又是如何出现于世呢？
一、系统架构演变：
我们来了解一下项目架构的发展史：具体可以分为：
- 单体应用架构
- 垂直应用架构
- 分布式架构
- SOA架构
- 微服务架构
我们一个一个来说各个架构的特性：
1.1单体应用架构：
互联网早期，大多数网站的应用流量都比较小，只需要一个应用，将所有的代码部署到一起就可以，这样可以减少开发，部署和维护的成本。
比如说一个电商系统，里边会包含很多用户管理，商品管理，订单管理，物流管理等等很多的模块，我们把他做成一个web项目，然后部署到一台服务器上。
他的优点就是：项目架构非常简单，小型项目开发成本低；
项目部署在一个节点上，维护方便
缺点：
- 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护（因为代码太多了呀）
- 项目模快之间紧密耦合，单点容错率低（一旦一个模块出错的话，呢么整个项目都会崩掉）
- 无法针对不同模块进行性能优化和水平扩展
- 高并发下服务宕机即GG
1.2 垂直应用架构
随着访问量的增大，我们会发现一个事实，就是项目的各个模块之间并不是每一个模块都有很高的访问量，但是将他们部署在一起，显然是不合理的。我们想给访问量大的模块增加性能，访问量小的不增加性能，这样单体就办不到了，所以就有了垂直应用架构出现了。
所谓的垂直应用架构，就是将原来的一个应用拆分成互不相干的几个应用，以提升效率，具体如下图所示，
这样，就会有一个好处，就i是，一旦用户的访问量变大，我们只需要增加访问量变大的呢个模块，就行，而不用每个都增大，比如说我们双十一，肯定用户的订单访问量会变大，而广告可能并没有变化，呢么我们只需要增加订单的模块数量就行了。
优点：
系统拆分实现了流量分担，解决了并发的问题，可以针对不同的模块进行优化和水平扩展（增加功能等等）
一个系统的问题不会影响到其他系统
缺点：
系统之间相互独立，无法进行相互调用
系统之间相互独立，无法进行代码复用
代码耦合度太高，不利于开发，加重了开发的任务
1.3 分布式架构
当垂直应用架构越来越多，重复的业务代码就会越来越多，这个时候，我们就思考可不可以将重复的代码提取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？？？
这样就产生了新的分布式系统架构，它把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑，表现层只需要处理和页面的交互就可以。
他的优点就是抽取了公共的代码和功能为服务层，提高了代码的复用性
缺点： 系统之间的耦合度变高，调用的关系错综复杂，难以维护，当有成百上千个服务的时候，根本不知道怎么样可以调用，或者说调用非常的麻烦，维护也非常的麻烦，而且，一旦一个服务出错，会影响到整个系统的功能，所有的功能都将瘫痪。
1.4SOA架构：
在分布式的架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需要增加一个服务调度中心对集群进行实时的管理，此时，服务治理中心是关键。
这样，好像各个服务之间的调用变得清晰明了起来了，但是还有一个问题就是，各个服务之间还是没有做到彻底分离，就是说，一个服务出问题还是会影响到别的系统的性能。
最主要的就是会发省服务雪崩事件：一个服务有问题，呢么接连着调用这个服务的别的服务也会等待，接连着受影响的服务就会越来越多，最后整个服务器就崩掉了
服务很复杂。
1.5微服务架构
于是，就出现了微服务架构，他是SOA架构继续发展的下一步，更强调隔服务之间的彻底分离
优点：
- 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
- 微服务之间采用Restful等轻量级http协议相互调用
缺点：
- 分布式系统开发的技术成本高（容错、分布式事务等）
二、微服务的各种概念和组件
一旦使用了微服务，我们就会面临这么几个问题：
- 这么多小服务，我们如何管理他们
- 这么多小服务，他们之间如何通讯
- 这么多小服务，客户端如何访问他们
- 这么多小服务，一旦出问题，如何处理
- 真么多小服务，出问题，如何定位？
这些问题，是任何一个微服务设计者都不能绕过去的，所以微服务的开发者们就针对这几个问题分别开发处理对应的组件来解决这几个问题，五大问题，分别对应了五大类组件：也就是文章开头的几个图架构
2.1微服务常见概念
上述提出了5个问题，分别对应了五个常用的概念，他们分别是：
- 服务治理：解决小服务之间的管理问题
- 服务调用： 解决小服务之间的通讯问题
- 服务网关：解决微服务客户端的访问问题
- 服务容错：解决微服务出现问题的解决
- 链路追踪：解决微服务出错的定位问题
1335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
