单体，SOA，微服务，分布式，集群架构知识来喽

–     单体架构     –

什么是单体架构

一个归档包（例如war格式或者Jar格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构，这是一种比较传统的架构风格。

单体架构示例图

–     单体架构的缺陷     –

1.复杂性高
整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。

2.技术债务逐渐上升
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。

3.部署速度逐渐变慢
随着代码的增加，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。

4.扩展能力受限，无法按需伸缩
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。

5.阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。由于单体架构的缺陷日益明显，所以越来越多的公司采用微服务架构解决上面提到的单体架构中的问题。不同于构建单一、庞大的应用，微服务架构将应用拆分为一套小且互相关联的服务。

 

–     SOA架构     –

SOA是Service-Oriented Architecture的英文缩写，就是面向服务的架构。这里的服务可以理解为service层业务服务。

–     单一应用架构     –

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

–     垂直应用架构     –

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

 

–     分布式服务架构     –

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

–     流动计算架构     –

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的SOA服务治理方案是关键。Dubbo就是SOA服务治理方案的核心框架。
总结：dubbo不仅可以对服务进行治理，而且还可以对服务进行调用。

–     微服务架构     –

简而言之，微服务架构风格的开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API轻量的机制来相互通信。

这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

微服务架构示例图

微服务架构的特性

每个微服务可独立运行在自己的进程里，一系列独立运行的微服务共同构建起整个系统。每个服务为独立的业务开发，一个微服务只关注某个特定的功能，如订单管理、用户管理等。微服务之间通过一些轻量的通信机制进行通信，如REST API接口进行调用，可以使用不同的语言与存储技术
全自动的部署机制

微服务架构的优势

1.易于开发和维护
一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态；

2.单个微服务启动较快
单个微服务代码量较少，所以启动会比较快；

3.局部修改容易部署
单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；

4.技术栈不受限
在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈

5.按需伸缩

 

微服务架构的挑战

1.运维要求较高
更多的服务意味着更多的运维投入。在单体架构中只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，带来了巨大的挑战；

2.分布式固有的复杂性
使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都带来了巨大的挑战；

3.接口调整成本高
微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整；

4.重复劳动
很多服务可能都会使用到相同的功能。而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。

微服务设计原则

单一职责原则
服务自治原则
轻量级通信原则
接口明确原则

 

–     微服务架构和SOA的区别     –

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化

微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

分布式-微服务-集群的区别

service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。

将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。

区别分布式的方式是根据不同机器不同业务。

注：分布式需要做好事务管理。

集群模式

集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。

区别集群的方式是根据部署多台服务器业务是否相同。

注：集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务。

一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。

分布式是否属于微服务?

答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。

微服务架构

微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。

微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。

分布式和微服的架构很相似，只是部署的方式不一样而已。