微服务学习（一）：微服务介绍

标签：含义   war   str   灵活   Kubernete   cap理论   mod   web   简单   

目录如下

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等。

微服务学习（一）：微服务介绍

标签：含义   war   str   灵活   Kubernete   cap理论   mod   web   简单   

原文地址：https://www.cnblogs.com/hello-jjj/p/11111819.html