微服务入门

微服务介绍

写这篇文章的初衷：希望带大家认识微服务，同时通过写博客的方式记录下自己对微服务的理解，希望大家看完文章能有所收获，也希望大家指出文章中描述不清或者错误的地方

---

前言

本篇文章主要介绍什么是微服务，为什么要使用微服务，现在微服务主要使用的架构

---

微服务是什么

微服务是一种开发软件的架构和组织方法，一个大型的应用由小型独立服务组成，这些独立的服务可以由不同团队去开发，部署和维护，各个服务之间通过定制的API去通信，完成服务与服务的交流。
这里大家如果不理解也没关系，可以继续往下看，等看完整篇文章再回过头来看，就很好理解这段话了。

使用微服务的好处

其实从上面的介绍就可以看出微服务一些特性，自主性和专用性；

专用性体现：主要体现在服务的划分，一个大的系统往往多个小型的服务去构成，这些服务都只负责自己负责的功能，可以实现功能的解耦和复用。所以服务的划分很重要！！！

举例：大家都比较熟悉的电商系统的用户服务，订单服务，库存服务等

自主性体现：因为是独立的服务，所以各个服务的技术选择，开发，部署都是独立的，这样可以由不同团队去负责开发，从而大大减少开发时间，也能是我们的技术选择以及服务部署更加灵活，扩展更加方便。

上面说到了把一个应用拆分成多个服务的好处，可能大家不是很理解，接下来我们可以比较一下现在的微服务架构和以前传统架构的区别，来看看为什么要使用微服务，这里涉及到一个架构演变的过程

单体架构：

早期的架构，简单来说，就是一个war包或者jar包包含一个应用的所有功能。

优点：能够快速开发和上线，运维成本低
缺点：耦合度高，不适合长期运营，只能满足用户量少，业务量小的应用

这里解释一下，单一架构的应用如果业务单一，用户量也不大的话，可以理解为整个应用比较简单，那么开发，部署包括运维成本都是很低的；但如果业务变化快，用户持续增长的话，就会暴露出很多问题。首先，业务的扩张会导致整个应用的代码量上升，后期一个war包的大小可能是好几GB大小，这时候因为业务变动，简单的修改也会导致整个应用的重新部署，上线。这个部署的过程会耗费大量的人力和时间。

垂直架构：
我们知道技术是用来支撑业务的，当上面提到的业务量上升时，我们就需要一个更好的架构来解决单一架构所面临的问题，接下来我们介绍垂直应用架构。如下图我们将之前的单体架构根据业务进行垂直拆分。

优点：通过系统的垂直拆分，业务解耦，解决了单一架构面临的耦合度高，不易扩展的问题

通过对业务的垂直拆分，我们可以让不同的系统由不同的团队去开发，部署和维护，这样就可以解决上面单一架构牵一发而动全身的问题，一定程度上实现了应用的解耦，是我们的业务能够更好的去扩张。同时可以通过多个tomcat服务器的部署减轻我们硬件的压力。

缺点：可能会出现大量重复代码，各个系统之间独立存在，无法通信。

1.大量重复代码：因为日常开发中我们肯定会遇到两个系统都存在相同的业务逻辑，假设我们库存系统中有一个查询商品数量的功能，但是我们在商品系统要完成下单，也要知道商品的数量，商品数量为零时，就会下单失败，那么这个查询商品数量的功能商品系统中也要有，就会出现业务逻辑上的重复。
2.各个系统之间独立存在，无法通信；通俗一点说，就是各个系统的业务和数据都是独立的，无法创造共同价值。

SOA:面向服务的架构
上面介绍了垂直架构，以及它的优缺点，既然有缺点，就会有新的更好的架构出现，下面介绍SOA，面向服务的架构。前面我们介绍的两种架构都只提到了系统，而SOA是面向服务的，它本质上也是一种思想的体现，类似于面向对象。上面我们提到的垂直架构的缺点，会在SOA中得到解决。

从上图可以看出，我们系统都是通过ESB（下面会介绍）去调用我们的服务，之前垂直架构遇到的相同业务逻辑的重复开发的问题就可以解决了，我们可以将重复的业务逻辑抽出来作为一个独立的服务，需要这个服务的应用直接去调用就可以了。同时，通过ESB我们将服务的调用者和服务本身完成了解耦 ，也实现了各个系统之间的通信。

什么是ESB

这里的ESB(企业服务总线)其实是一个比较宽泛的概念，它的主要作用是用来管理服务和数据传输，服务提供者只需要将服务注册到ESB，需要这个服务的应用就可以通过ESB获查找到这个服务，也可以完成数据的传输，从而解决无法进行信息交换的问题。

例： 我们平常使用的dubbo+zookeeper的服务注册和调用也是ESB的一种实现

总结一下上面的内容：

在介绍微服务架构之前，我们总结一下上面的内容，从单一架构——>垂直架构——>再到SOA（面向服务的架构），我们发现架构都是为了贴合我们的实际业务去演进，当前的架构无法满足我们的业务的时候，我们就需要一个更适合业务的架构。这里其实我们需要思考下，SOA就一定比我们前面提到的架构好吗，其实这个问题需要结合我们业务去思考，没有最好的架构，只有最合适的架构，不贴和业务的技术架构都是耍流氓。所以微服务架构也不是盲目的去使用的，而是要考虑我们的业务是怎么样的，用户的体量是怎么样的。

微服务架构：
上面我们的已经介绍过了SOA,其实它提出的是一种全新的思想，面向服务，微服务架构本质上其实也是面向服务的思想的一种实现。它和SOA的区别首先从关注点出发去考虑，SOA是为了解决服务的复用和各系统之间的通信，而微服务更多关注的是服务的解耦，它的目的是降低我们业务的耦合度，也就是虽然都是面向服务的思想，但是微服务的拆分粒度更小，对业务的复用性要求更高。这样的服务拆分可以使我们在业务多变，数据量持续上升的场景下更好的去扩展我们的服务，也可以使我们整个系统的稳定性更高，同时对系统的构建，发布和运维也有更高的要求。

这里大家可能会发现服务的划分和SOA差不多，但其实微服务的划分可以更细，只是我这里没有画出来

到这里大家再回头看微服务的定义，应该都能理解什么是微服务架构了，也明白为什么要使用微服务架构，我们不妨总结一下微服务的优点：

1.技术选型灵活
2.可独立开发，部署，更灵活
3.复杂度可控，每个微服务只需关注自己的业务即可
4.可扩展性高
5.容错性高（后面讲到服务的降级，熔断会介绍）

这里我们也要抛出微服务所面临的一些挑战：

1.前期的准备工作变多，服务的拆分要优先规划好
2.问题排查变难，因为多个服务互相调用会形成一个调用链
3.服务的监控
4.分布式框架的复杂性，服务的高可用，数据的一致性都要考虑、
5.运维的成本，要保证几十个或者上百个服务的正常运行

既然有挑战，那也就会有解决这些问题的技术，接下来我们看一下一个简单的微服务技术架构应该什么样的

如上图我们会发现一个微服务架构中包括了服务本身，网关，注册中心，配置中心，链路监控，日志监控等等，这些我们都可以称之为微服务组件，这个架构中的每个组件都有自己作用，用来解决微服务架构所面临的挑战，
，例如网关可以实现负载均衡，服务的路由，限流，注册中心和配置中心可以用来治理我们的服务等等。

本篇总结：
本篇文章的最后向大家提到了微服务的组件，没有接触过微服务的同学可能看到最后不是很理解，不过没关系，本篇文章的主要目的是带大家了解微服务，如果大家看完后能理解什么微服务，别忘记给花荣点点赞啊，毕竟大家的支持才是我更新的动力；
下篇预告：
基于本篇最后提到的微服务技术架构和组成组件。下篇会为大家带来一个生产环境下的完整的微服务架构是什么样的，其中会有哪些组件，以及这些组件的介绍和起到的作用，后续也会持续更新微服务相关的内容，带着大家从微服务入门，到熟练掌握微服务，并运用到实际开发中，求关注~