很多小伙伴都知道，现在入行程序员真的太难了，被淘汰的程序员真的太多太多了，第一，时代技术的进步，我们的思维也要不断的创新。第二，我们抓不到技术核心知识点，面试官一问三不知或者回答的太简单很容易被拒。总结来说我们要认识到自己的要害问题，把实操技术练好，学习中心核心技术对你的前程真的很重要。获取更多核心技术笔记在文末领取。好了，废话不多说，直接进入主题。
垂直应用架构
垂直应用顾名思义，就是层级之间的排列是垂直的，为什么是垂直的？
特点：
1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。
2、项目与项目之间的存在数据冗余，耦合性较大。
3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。
优点：
1、解决高并发问题（如果用户中心访问的人数过多，我们只需要对用户中心进行单一的集群部署）
2、方便水平扩展，容错(用户中心出现问题，商品系统，后台系统还可以正常访问)
3、通过垂直拆分，原来的单体项目不至于无限扩大。
4、不同的项目可采用不同的技术。
缺点：
1、系统之间太过于独立(彼此之间有联系，有需要互相调用的，怎么办。应用之间的交互，已经达到了不可避免的地步)
2、重复开发工作(每个独立的项目都会出现重复性的的代码)
单体应用架构
特点：
1、所有的功能集成在一个项目工程中。
2、所有的功能打一个war包部署到服务器。
3、应用与数据库分开部署。
4、通过部署应用集群和数据库集群来提高系统的性能。
优点：
项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：
(1):复杂性高
一个百万行级别的单体应用为例，整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐，混乱地堆砌在一起……整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。
(2):技术债务
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。
(3):部署频率低
随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。
(4):扩展能力受限
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，我们不得不在硬件的选择上做出妥协。
(5):阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和框架，想要引入新的框架或技术平台会非常困难。例如，一个使用Struts 2构建的、100万行代码的单体应用，如果想要换用Spring MVC，切换成本无疑是非常高的。
RPC架构
特点：
1、服务消费者（client客户端）通过调用本地服务的方式调用需要消费的服务；
2、客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体；
3、客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；
4、服务端存根（server stub）收到消息后进行解码（反序列化操作）；
5、服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；
6、本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）；
7、服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方；
8、客户端存根（client stub）接收到消息，并进行解码（反序列化）；
9、服务消费方得到最终结果；
而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。
优点：
1. 提升系统可扩展性
2. 提升系统可维护性和持续交付能力
3. 实现系统高可用
缺点：
1. 一个完善的RPC框架开发难度大
2. RPC框架调用成功率受限于网络状况
3. 调用远程方法对初学者来说难度大
dubbo不只是一个RPC框架，还是一个服务治理框架
SOA服务化架构
优点：
a.可从企业外部访问；b.随时可用；c.粗粒度的服务接口分级；d.松散耦合；e.可重用性的服务；f.服务接口设计管理；g.标准化的服务接口；h.支持各种消息模式；I.精确定义的服务架构。
1.增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。
2.加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。
3.因为模块化，所以系统模块重用度更高
4.因为软件服务模块被拆分，开发和发布速度可以并行而变得更快
5.系统扩展性更高
6.团队协作流程也会得到改善
面向服务架构（SOA）是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信。他可以根据需求通过网络对松散耦合的粗粒度的应用组件进行分布式部署、使用和组合。SOA能够帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统架构能够更加从容的面对业务的急剧变化。
企业服务总线（ESB）是由中间件技术实现的全面支持面向服务架构的基础软件平台，支持异构环境的服务以及基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。
缺点：
1.架构设计变得复杂（尤其是其中的分布式事务）
2.部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂
3.系统的吞吐量会变大，但是响应时间会变长
4.运维复杂度会因为服务变多而变得很复杂
5.架构复杂导致学习曲线变大
6.测试和查错的复杂度增大
7.技术可以很多样，这会带来维护和运维的复杂度
8.管理分布式系统中的服务和调度变得困难和复杂
微服务架构
特点：
微服务架构是一种松耦合的、有一定的有界上下文的面向服务架构。
也就是说，如果遇到一个功能变更, 但其要求每个服务都要同时修改，那么它们就不能称之为微服务，因为它们紧耦合在一起；如果你需要掌握一个服务的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义一般来自DDD（领域驱动设计）。
优点：
1.微服务是松藕合的，无论是在开发阶段或部署阶段都是独立的。
2.能够快速响应, 局部修改容易, 一个服务出现问题不会影响整个应用。
3.易于和第三方应用系统集成, 支持使用不同的语言开发, 允许你利用融合最新技术。
4.每个微服务都很小，足够内聚，足够小，代码容易理解。团队能够更关注自己的工作成果, 聚焦指定的业务功能或业务需求。
5.开发简单、开发效率提高，一个服务可能就是专一的只干一件事, 能够被小团队单独开发，这个小团队可以是 2 到 5 人的开发人员组成。
缺点：
微服务架构带来过多的运维操作，可能需要团队具备一定的DevOps技巧。
分布式系统可能复杂难以管理。因为分布部署跟踪问题难，当服务数量增加，管理复杂性增加。
总结
太多太多了 我就不全部罗列出来了 ，这篇技术文对您们的帮助很大，不管是平时面试，或者平常工作中都是需要的。全部资料我已经打包好，可以点赞+转发+关注。然后小信封回复【444】即可获取全部技术核心资料。
