技术干货：单体,SOA, 微服务, 分布式, 集群架构详解，java 开发面试简历
不同于构建单一、庞大的应用，微服务架构将应用拆分为一套小且互相关联的服务。
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 进行业务访问。
将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论