微服务学习(一):微服务介绍

目录如下

  1. 软件架构的进化
  2. 微服务的优势和不足
  3. 微服务架构所带来的问题及解决方案

1.软件架构的进化

于笔者经历来看 架构大致从
单体架构 》MVC 》 微服务

  • 单体架构

    单体架构特点在于所有功能业务打包在一个发布包里,部署在一个web容器中,运行在一个进程里。单体架构的优点在于
    • 容易开发 -- 一个人就可以写了,但是你想想这个后期其他人维护。。。。
    • 容易测试 -- 所有功能都在一个进程里嘛,测试就简单了
    • 容易部署 -- 比如一个war包 丢服务器上就好了
      缺点
    • 维护困难 -- 代码量之后越来越庞大,新人根本难以上手,不知道经过多少人修改过。。
    • 部署困难 -- 随着代码变得庞大,部署和启动的时间也会变长
    • 不稳定 -- 牵一发而动全身,一个错误就gg
    • 扩展不灵活 -- 垂直扩展非常困难
  • MVC

    MVC这个名词曾经困扰了笔者很久,根本理解不来这三个英文单词的拼写,笔者认为这些名词拿出来就是让别人看不懂的,根本不需要去想Model,View,Controller这几个名词所代表的含义,它的出现解决了代码杂乱无章,职责不清晰的问题,通过在各层之间定义接口,再将接口与实现分离,可以更好替换实现方案,也更容易让别人看懂代码,近期常见的SSM与SSH就是MVC的实现。
  • 微服务

    什么是微服务呢?
    其实微服务就是一种架构风格。比较官方的定义就是从马丁大叔的博客中取得

    使用一系列微小服务来开发单个应用的方式,每个服务运行在独立的进程里,一般采用轻量级的通讯互联机制,并且可以通过自动化的方式部署

    综合马丁大叔的这段话,笔者认为微服务主要特点就在于
    • 一系列微小的服务
    • 独立的进程
    • 轻量级的通讯
    • 自动化部署
    那么什么样的服务可以叫做微服务--也就是单指其中一个服务
    特征在于
    • 单一职责 -- 例如只有注册登录可以放在一个服务里,商品服务就别扔进来了
    • 轻量级通讯 -- 语言无关,平台无关
    • 隔离性 -- 运行在自己的进程中
    • 独立数据源 -- 就是有自己独立的数据库
    • 技术多样性 --跨语言的嗷~~

2.微服务的优势与不足

  • 优势

  • 独立性 -- 每个服务接收到的访问量也就是QPS是不同的,因为进程独立的原因,我们可以为其单独配置硬件环境,修改代码也不会影响别人
  • 敏捷性 -- 可以快速进行开发,每一个微服务都很简单(不然拆分出来干啥)
  • 不足

  • 如何进行服务拆分 -- 就。。很难
  • 数据一致性 -- 不同于单体只有一个数据库,微服务有很多数据库(有关这个大家可以去看一下什么叫CAP理论)
  • 沟通成本 -- 也就是服务间的调用沟通

3.微服务带来的问题及解决方案

  • 微服务之间如何通讯

    1.httpclient进行通讯
    2.RPC--远程过程调用,调用远程服务和本地服务一模一样,调用实现对用户透明
  • 微服务之间如何发现彼此

    微服务的发现分 服务端发现和客户端发现,SpringCloud就是服务端发现,Dubbo就是客户端发现,微服务的发现需要有一个服务发现和注册中心,即SpringCloud采用的eureka和Dubbo所采用的zookeeper,各个微服务将自己注册到服务发现注册中心,服务发现注册中心将他们记录之后,通过服务注册中心,微服务们就可以互相发现和调用彼此。

  • 微服务之间如何部署,扩容,更新

    有关此问题将在后面章节中具体阐述,本章只作简略描述
    为解决此问题,我们就必须认识一个名词叫做服务编排,服务编排就解决了微服务遇到的部署更新和扩容问题,而现在也有许多服务编排的工具例如Mesos,Docker Swarm,Kubernetes等。

猜你喜欢

转载自www.cnblogs.com/hello-jjj/p/11111819.html