1.单体架构与微服务的区别

单体架构

什么是单体架构

单体架构也叫做单体系统。是把所有功能、模块耦合在一个系统里。例如mvc系统。

单体架构的特点

1.打包部署时打成一个独立的单元，例如jar包、war包。
2.整套系统只有一个进程。（最大特点）

单体架构的缺点

测试部署问题

测试部署成本高：任何程序改变，需要把整个系统重新部署。

伸缩性

可伸缩性差：单进程局限性使系统在水平扩展的时只能基于整个系统扩展，无法针对某一功能模块按需扩展。例如：电商系统包含用户、商品、订单、交易、支付模块。无法做到只对商品单个模块做集群。

可靠性

可靠性差：单体系统中某一个模块出现bug例如：死循环、内存溢出，会导致整个进程宕机，影响整个系统。

系统迭代

每个功能迭代后合并非常麻烦

跨语言程度

整个系统统一的技术栈，管理起来看似简单。但有时候统一标准并不一定适用于所有实际情况。例如某些适用场景java不一定比其他语言好。

团队协作

整个系统一个团队，如果系统变得庞大，成员就需要学习大量代码和领域知识，团队内沟通和协作也会变得低效。

微服务架构

什么是微服务架构

微服务是一种架构风格，简单的说就是把一个独立系统拆分成多个小型服务，每个服务独立部署，服务之间使用RESTful API进行通信协作。每个服务高内聚（体现在每个服务只做一件事），服务之间低耦合。

微服务架构的特点

1.将“巨石”服务，解耦成简单独立服务
2.独立进程
3.服务间通信简单

微服务架构的优缺点

测试部署问题

测试部署成本低：每个微服务组件都是简单灵活的，能够独立部署。

伸缩性

可伸缩性好每个微服务都是高内聚，服务之间低耦合很容易按服务进行扩展。例如：电商系统包含用户、商品、订单、交易、支付模块。可以单独把商品模块做集群。

可靠性

可靠性强：不会因为某一个BUG导致整个系统宕机,因为各个服务之间是松耦合的关系不是强制依赖。

系统迭代

迭代高效：每个服务由对应团队迭代。

跨语言程度

不限制语言：每个服务之间使用RESTful通信。

团队协作

团队按微服务配置，成员专注于小的领域和代码集。沟通成本低，容易学习。

微服务带来的问题

1.运维成本高：微服务部署数量多，监控进程多导致整体运维复杂度提升。
2.接口的多版本开发：面向服务开发就是面向接口开发，一般接口的变更会导致多个客户端跟着改，这就必须做接口的多版本开发。
3.分布式系统的复杂性：本来一个系统，把他分成多份就会导致网络延迟、服务容错性、服务的负载均衡等等。
4.分布式事物：微服务开发带来的难题就是分布式事物的处理。