微服务架构设计模式与CAP定理

微服务架构设计模式与CAP定理

前言

       hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。微服务呢,在大学期间最后一年也学过,但是工作后却用的比较少。为了防止以后公司业务需要用到微服务的时候,我不至于一脸懵然后还要临时学,所以这个国庆打算对微服务进行一个总结。计划是花五天时间。首先我要声明一下,自己是个菜鸟,如果总结的不好或者很糟糕欢迎指出我们大家一起学习。嘿嘿~

微服务有什么用?

       在早期的互联网开发中,包括现在也有很多的项目都是单体的应用程序。一般这个单体的应用程序是由客户端用户界面,模块和数据库三个部分组成。一般模块会有很多个,最后打成一个包部署在服务器上。在项目的早期阶段,这样的方式会比较容易开发,部署也方便。可是到了后期麻烦可就大了,因为随着用户需求的增加项目功能也会跟着扩展。之前的小应用会变得越来越复杂。一旦出现了Bug就会牵一发而动全身,所以说在单体应用中每个服务的更新和改变都会导致重新部署整个应用,灵活性太低...而分布式就是解决这个问题的。

       微服务顾名思义其实就是把一个庞大的应用程序拆分成一套小而互联的服务。

SOA架构

       SOA架构它是面向服务的,在单体架构的基础上按照业务功能进一步进行垂直拆分。每一个服务都包含了自己的业务逻辑和多个适配器。把模块拆分再用接口互相通信。就像我们搞开发前后端分离一样,后端使用Responsebody发Json给前端,前端根据后端的接口得到数据。这样在开发的时候,谁都不用等谁先做,各顾其职就好了。SOA架构通常以独立的形式存在于操作系统的进程中,每个服务之间通过网络通信。而微服务的话呢,它其实就是对SOA的拆分进行再拆分。微服务架构比SOA架构拆分的更加彻底。

微服务架构常见的设计模式

聚合器微服务设计模式