单体架构、SOA和微服务
1.定义
单体架构：
单体架构就是把所有功能逻辑全部放在一个项目里，打包发布的时候以一个jar或war包的形式发布，部署简单，但是随着业务流量或网站流量的增加，必然暴露其致命缺陷（后续说明）
SOA(Service Oriented Architecture，面向服务的体系结构)：
旨在提升代码的复用性以及可扩展性和降低耦合度等。如：点外卖的流程，点了外卖之后要分配送餐员，分配送餐员可以是一个服务；还有可能要发短信通知，发短信也可以是一个的服务，服务之间可以独立部署运行，服务之间可以通过网络调用，这样服务朱合起来就是一个完整的系统
微服务：
微服务是由多个功能单一的小服务组成的，服务可以通过业务功能设计拆分；这些服务独立部署；不同的服务可以使用不同的技术实现（指不同的语言和数据库等）；服务与服务之间此阿勇HTTP等轻量协议传输数据，服务之间独立性强，还能提升代码复用性以及可扩展性和降低耦合度等
2.为什么使用微服务以及优缺点
单体架构
业务初期，功能足够简单且网站流量不大的情况下，的确是一个低成本且效率高的方案
不过随着时间推移，流量增大，就会暴露其缺陷：
（1）代码复杂度高
因为所有代码柔和在一起，依赖紧密，可能修改一处会带来“迁一而发动全身”的风险。
（2）体积大，部署缓慢
目前遇到的最大的项目打包是500MB左右，如果更新频繁，重新打包、发布将是一个磨人的过程
（3）程序出错影响服务器稳定
如果程序某个功能出现bug，将会导致大量的占用系统资源（如死循环）。因为是单体架构，会导致用户请求缓慢，严重的可能导致服务器宕机
（4）阻碍技术的更新
单体应用往往只能使用当前项目的编程语言和现有的框架开发，如果映入新的框架可能会不兼容
（5）集群扩容不合理
假设网站流量网站增大了，以前单个服务器支撑不了，那么使用负载均衡器（一般是Nginx）做一个集群，现在就有两个服务了。但是这样做不合理，因为网站流量增大只是给用户使用的功能流量增大，像管理员使用后台管理并没有太大的变化，现在是整体扩容，服务无法结合实际业务伸缩，从某个角度讲其实是造成了资源浪费。
（6）历史遗留问题
一般经历过几年的单体应用，都经历过很多程序员的改动，由于每个人的编程能力和风格不同，就有可能出现代码的“坏味道”，但又不能轻易修改，俗称“祖传代码”
SOA
微服务是SOA体系不断推演的结果，SOA与微服务本质上都是拆分服务，但是微服务比SOA更突出服务独立性，更细粒度的划分服务。如：短信服务可以划分为营销短信服务、订单短信服务等。这个拆分粒度界限没有统一的标准，需要自己去权衡利弊。
微服务
优点：
（1）代码复杂度低
根据业务细粒度拆分成多个小服务，雨雾功能清晰，代码体积小，便于理解和维护
（2）技术选型不被束缚
单个服务可以根据自身业务选择合适的语言和技术栈实现
（3）独立部署
如果修改一个后台管理服务，就只需要重新部署这个服务，其它的主业务不动，不仅影响范围小，也减少了部署和测试的时间。
（4）服务的可伸缩性
根据自身业务发展的实际情况，哪个服务承载量达到了上线，就多部署一些节点，或者是增加该服务器的配置；相应的哪个服务流量小，就减少服务节点，或者降低该服务器的配置
（5）错误隔离
在多个服务器中加入后台管理宕机了，但是给用户提供的服务程序正常运行，错误只会影响管理员操作后台，丝毫不影响用户的体验
（6）分库变得容易
因为微服务会拆分为多个应用，每个应用可以单独的连接一个数据库，这样可以在一定程度上省去分库的成本
缺点：
（1）构建微服务系统复杂
构建微服务并不是简单的服务调用，要充分考虑网络延迟和网络故障带来的影响
（2）服务依赖
假设有A、B、C三个服务，A调用B，B调用C，C是最底层的服务，如果此时迫不得已要改动C的接口，可能B也要改动，也可能A也要改动
（3）数据一致性问题
在微服务中，各个服务都是独立的进程，假设A服务调用B服务，在远程调用过程中，刚好遇到网络延迟，A系统收到超时异常数据回滚，可是在B系统已经将数据保存了
（4）接口排除故障困难
随着微服务调用链路的拉长，要定位线上的问题，不得不同时查看多个服务情况
（5）运维和部署
要检查和监控多个服务的健康状态，快速的部署多个服务，并且根据网站负载情况实现服务的动态伸缩等。