微服务简介

1.1 单体架构

简介: 通常来说，如果一个war包或者jar包里面包含一个应用的所有功能，则我们通常称这种架构为单体架构。 如图:

此架构的优势: 足够简单,能够快速开发和上线   ||  劣势： 如果用户量很大,这样的架构不足以支撑业务的正常运行

1.2 集群和垂直化

随着业务的不断发展,产品被越来越多的人使用,对于整个技术架构来说,可能面临很多的挑战.

1️⃣: 用户量越来越大,网络访问量越来越大，后端服务器负载越来越高.

2️⃣： 用户量增大,需要满足不同用户的需求来留住用户，随之而来的业务越来越复杂.

3️⃣：服务器负载越来越高,响应速度越来越慢,如果不进行优化，会损失大量用户.

4️⃣：业务的场景越多，越复杂 代表着war包代码里会持续升高,各个业务代码之间的耦合度也会越来越高,后期的维护会越来越困难.

因此,我们需要作出优化:

1. 通过横向增加服务器,把单台服务器变成多台服务器的集群。

2. 按照业务的垂直领域进行拆分,减少耦合度.

如图：

1.3 SOA(Service-Oriented Architecture)

  现在让我们来举个例子来简单说明一下SOA:

· 假如一个用户执行下单操作,首先要先去库存子系统检查商品的库存，只有库存足够的情况下才会提交订单，那么这个检查库存的逻辑是放在订单子系统中还是库存子系统中？在整个系统中一定会产生很多类似的业务场景,这些业务场景的逻辑被重复创建会产生非常多于的代码，这些代码随着时间的推移成本会越来越多，那为什么不把这些共享业务逻辑抽离出来形成可重用的服务?

· 在一个集团公司下有很多子公司，每个子公司都有自己的业务模式和信息沉淀，各个子公司之间不进行交互和共享。这个时候每个子公司 虽然能够创造一定的价值，但是由于各个子公司之间信息不是互联互通得到,彼此之间形成了信息孤岛，使得价值无法最大化。

基于这些问题，就引入了SOA ， 面向服务的架构，根据上面的问题我们不难看出，SOA中解决的问题是1. 信息孤岛 2. 共享业务的重用，业务被划分为一些粗粒度的业务服务和服务流程.

如图:

 1.4 微服务架构

        业务系统实施服务化改造之后，原本共享的业务被拆分形成可复用的服务，可以在最大程度上避免共享业务的重复建设等问题，那么背拆分出来的服务是否也需要以业务功能为维度来进行拆分和独立部署，以及降低业务的耦合度及提升容错性呢？

        微服务就是这样的一种解决方案。但是微服务又和上面说的SOA不一样，两者有很大的区别:

   · SOA 关注的是服务的重用性以及解决信息孤岛问题。

    · 微服务关注的是解耦，虽然解耦和可重用性在特定的角度看来是一样的，但在本质上有很大的区别，解耦是降低业务之间的耦合度，而重用性关注的是服务的重用。

     · 微服务会更多地关注DevOps的交付上，因为服务粒度细化之后式的开发运维变得更加重要，因此微服务根容器化技术结合的更加紧密.

如图: 微服务的粒度越小，服务独立性带来的好处就越多，但是管理大量的微服务也会更加复杂