随着业务的发展我们的项目从简单的单体结构逐渐的演化成微服务结构, 我们为什么要拆分成微服务呢？那我们就来说说微服务和单体架构的优缺点吧。
单体架构
单体架构优点
部署容易: 如 php 写的项目，只要一个文件夹复制到支持 php 的环境就可以了，java 只需要一个 jar 包
测试容易: 我们整体项目只要改了一个地方马上就可以测试得出结果
负载均衡就可以解决: 快速部署多个一模一样的项目在不同的机器运行分流
技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发
用人成本低: 单个程序员可以完成业务接口及数据库的整个流程
单体架构缺点
部署的问题: 对于 php 来说这点还好，但是对于 java 的项目来说，我们需要重新打包整个项目耗费的时间是很长的
代码维护: 由于所有的代码都写在一个项目里面，要想要修改某一个功能点那么需要对项目的整体逻辑和设计有较深的理解，否则代码耦合严重，导致维护难，特别对于新入职的员工来说这将是最容易出现问题的地方
开发效率低: 随着项目需求的不断改变和新的功能新增，老旧的代码又不敢随便删除，导致整个项目变得笨重，这将会增加你阅读代码的时间
系统启动慢: 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动时间周期过长
可伸缩性差: 系统的扩容只能对这个应用进行扩容，不能做到对某个功能点进行扩容。在高并发的情况下，我们往往不是整个项目的每一个功能都处于高流量高请求的情况下的，很多时候都是某一个功能模块使用的人数比较多，在单体结构下我们没有办法针对单个功能实现分布式扩展，必须整个项目一起部署
系统错误隔离性差: 可用性差，任何一个模块的错误均可能造成整个系统的宕机
线上问题修复周期长: 任何一个线上问题修复需要对整个应用系统全面升级
微服务架构
在2014年被提出，现在国内很多公司已经使用，微服务是一种架构设计，并不是说什么框架或者代替什么。微服务做的事情是按照项目颗粒度进行服务的拆分，把模块单独拿出来做成每一个单独的小项目。微服务的主要特点有：每一个功能模块是一个小项目、独立运行在不同进程或者机器上、不同功能可以又不同的人员开发独立开发不松耦合、独立部署不需要依赖整体项目就可以启动单个服务、分布式管理。每一个服务只要做好自己的事情就好了。在设计微服务的时候还需要考虑到数据库的问题，是所有微服务使用共同一个数据库还是每一个服务单个数据库。
服务调用
每个服务间也可以相互调用(即:双向流调用), 可以通过 RPC、GRPC 这类远程调用方式。调用者与服务之间的通讯，传输协议可基于 TCP、UDP 或者 HTTP 实现，但是更推荐选择 TCP。
例如调用者需要调用商品的服务就可以通过 RPC 或者 RESTful API 来调用，那么 RPC 调用和 RESTful API 两者之间的区别在哪呢？
- TCP 支持长连接，当调用服务的时候不需要每次都进行三次握手才实现。从性能和网络消耗来说 RPC 都具备了很好的优势
- RESTful API 基于 HTTP 的，也就是说每次调用服务都需要进行三次握手建立起通信才可以实现调用，当我们的并发量高的时候这就会浪费很多带宽资源
- 服务对外的话采用 RESTful API 会比 RPC 更具备优势，因此看自己团队的服务是对内还是对外
RPC 最主要的作用就是用于服务调用
微服务架构优点
易于开发和维护: 一个微服务只会关注一个特定的业务功能，所以他的业务清晰，代码量少，开发和维护单个微服务相当简单，而整个应用是若干个微服务构建而成的，所以整个应用也被维持在一个可控状态。拆分业务，把整体大项目分割成不同小项目运行在不同进程或者机器上实现数据隔离
技术栈不受限: 每个服务可以由不同的团队或者开发者进行开发，外部调用人员不需要操心具体怎么实现的，只需要类似调用自己方法一样或者接口一样按照服务提供者给出来的参数传递即可
独立部署: 每一个服务独立部署，部署一个服务不会影响整体项目，如果部署失败最多是这个服务的功能缺失，并不影响其他功能的使用
按需部署: 针对不同的需求可以给不同的服务自由扩展服务器，根据服务的规模部署满足需求的实例
局部修改容易部署: 当一个服务有新需求或者其他修改，不需要修改整体项目只要管好自己的服务就好了
单个微服务启动较快: 单个微服务代码量较少，所以启动会比较快
按需收缩: 可根据需求，实现细粒度的扩展，例如：系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存，升级CPU或者增加节点
可以承受高并发
微服务架构缺点
运维要求较高: 更多的服务意味着更多的运维投入，在单体架构中，只需要保证一个应用的正常运行，而在微服务中，需要保证几十甚至几百个服务正常运行与协作，这给运维带来了很大的挑战
分布式固有的复杂性: 使用微服务构建的是分布式系统，对于一个分布式系统，系统容错，网络延迟等都会带来巨大的挑战
接口调整成本高: 微服务之间通过接口进行通信，如果修改某一微服务API，则所有使用该接口的微服务都需要调整
评论一下？