目录如下
- 软件架构的进化
- 微服务的优势和不足
- 微服务架构所带来的问题及解决方案
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等。