八种架构设计模式及其优缺点
10种常见的软件体系架构模式分析以及它们的用法、优缺点
10种常见的软件体系架构模式分析以及它们的用法、优缺点有没有想过要设计多大的企业规模系统？在主要的软件开发开始之前，我们必须选择一个合适的体系结构，它将为我们提供所需的功能和质量属性。
因此，在将它们应用到我们的设计之前，我们应该了解不同的体系结构。
根据维基百科中的定义：
架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。
架构模式与软件设计模式类似，但具有更广泛的范围。
在本文中，将简要地解释以下10种常见的体系架构模式，以及它们的用法、优缺点。
一. 分层模式
这种模式也称为多层体系架构模式。
它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。
每个层都为下一个提供更高层次服务。
一般信息系统中最常见的是如下所列的4层。
•表示层(也称为UI层)•应用层(也称为服务层)•业务逻辑层(也称为领域层)•数据访问层(也称为持久化层)
使用场景：•一般的桌面应用程序•电子商务Web应用程序
二. 客户端-服务器模式
这种模式由两部分组成：一个服务器和多个客户端。
服务器组件将为多个客户端组件提供服务。
客户端从服务器请求服务，服务器为这些客户端提供相关服务。
此外，服务器持续侦听客户机请求。
使用场景：•电子邮件，文件共享和银行等在线应用程序
三. 主从设备模式
这种模式由两方组成;主设备和从设备。
主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是由从设备返回的结果。
使用场景：•在数据库复制中，主数据库被认为是权威的来源，并且要与之同步•在计算。
细谈8种架构设计模式及其优缺点
细谈8种架构设计模式及其优缺点一、什么是架构我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果，哈哈，我理解，架构就是骨架人类的身体的支撑是主要由骨架来承担的，然后是其上面的肌肉、神经、皮肤。
架构对于软件的重要性不亚于骨架对人类身体的重要性。
二、什么是设计模式这个问题我问过的面试者不下数十次，回答五花八门，在我看来，模式就是经验，涉及模式就是涉及经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计。
这样可以大大节省我们的设计时间，提高工作效率。
作为一个老码农，经理的系统架构设计也不算少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。
总体而言，有八种，分别是：1、单库单应用模式：最简单的，可能大家都见过2、内容分发模式：目前用的比较多3、查询分类模式：对于大并发的查询、业务。
4、微服务模式：适用于复杂的业务模式的拆解5、多级缓存模式：可以把缓存玩的很好6、分库分表模式：解决单及数据库瓶颈7、弹性伸缩模式：解决波峰波谷业务的流量不均匀的方法之一8、多机房模式：解决高可用、高性能的一种方法三、单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用业务层完成的，所有的数据也都是存储在一个数据库中，好一点会有数据库的同步，虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求。
缺点：性能差、基本没有高可用、扩展性差，不适合用于大规模部署、应用等生产环境。
四、内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是采用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器，这种模式的一般设计见下图：如上图所示，这种模式较单库单应用的模式多了一个CDN、一个云存储OSS（七牛、又拍等雷同）。
企业级应用的架构与设计模式
企业级应用的架构与设计模式随着互联网的普及和技术的不断发展，企业所面临的竞争压力也日益加大。
为了应对这些挑战，企业需要构建稳定、可靠和高效的应用系统。
这就要求企业级应用具备良好的架构和设计模式，以支持系统的可扩展性、可维护性和可伸缩性。
本文将介绍一些常见的企业级应用架构和设计模式，并探讨它们的优缺点。
1.分层架构分层架构是一种常见的企业级应用架构，它将系统划分为多个层次，每个层次都有特定的责任和功能。
通常分为以下几个层次：-表现层：负责处理用户界面和展示逻辑。
-业务逻辑层：负责处理业务逻辑，对外提供服务接口。
-数据访问层：负责与数据库进行交互，处理数据的增删改查操作。
-数据库层：负责存储和管理数据。
分层架构的主要优点是代码的组织清晰，各层之间的关系明确，便于开发和维护。
同时，它也提供了很好的可扩展性，可以根据需要添加新的层次。
然而，分层架构也存在一些缺点，比如层次过多会增加开发复杂度和性能开销。
2.微服务架构微服务架构是一种将应用拆分为多个小型服务的架构模式。
每个服务都是一个独立的单元，有自己的数据库和业务逻辑。
它们之间通过轻量级的通信机制进行交互。
微服务架构的主要优点是松耦合、独立部署和可扩展性。
每个服务都可以独立开发、测试和部署，可以更灵活地响应变化和需求。
然而，微服务架构也增加了系统的复杂度，对运维人员的要求更高。
3.事件驱动架构事件驱动架构是一种基于事件和消息传递的架构，应用系统中的每个组件都是一个事件的消费者或生产者。
当事件发生时，系统会相应地作出反应。
事件驱动架构具有松耦合的特点，可以实现系统的高度可伸缩性和可扩展性。
同时，它也提供了更好的可维护性和灵活性。
然而，事件驱动架构也带来了一些挑战，比如事件的处理顺序、数据一致性和错误处理等问题。
4.MVC设计模式MVC（Model-View-Controller）设计模式是一种常见的架构模式，将应用系统划分为三个组件：模型、视图和控制器。
软件架构设计：选择合适的架构模式
软件架构设计：选择合适的架构模式在软件开发过程中，选择合适的架构模式对于构建高效、可扩展和可维护的软件系统至关重要。
架构模式是一种在设计阶段用于解决常见问题的通用解决方案，它提供了一种结构化的方法，帮助开发团队组织和管理系统的各个组件。
本文将介绍几种常见的架构模式，并且讨论如何选择合适的架构模式。
首先，我们来介绍一下几种常见的架构模式。
1.分层架构模式：分层架构模式将软件系统划分为多个层次，每个层次负责完成不同的功能。
常见的层次包括表示层、业务逻辑层和数据访问层。
这种模式的优势是各个层次之间的耦合度较低，易于维护和修改。
2. MVC架构模式：MVC是Model-View-Controller的缩写，是一种将软件系统分为三个部分的架构模式。
Model负责处理逻辑和与数据交互，View负责向用户展示数据，Controller负责协调Model和View 之间的通信。
这种架构模式的优势是松散耦合，易于测试和维护。
3.客户端-服务器架构模式：客户端-服务器架构模式是将软件系统分为两个独立的部分，客户端负责与用户进行交互，服务器负责处理业务逻辑和数据存储。
这种模式的优势是可扩展性和灵活性。
4.微服务架构模式：微服务架构模式将一个大型系统拆分成多个小的、独立的服务。
每个服务都有自己的数据库和接口，可以独立部署和扩展。
这种模式的优势是可伸缩性和灵活性。
选择合适的架构模式需要考虑多个因素。
首先，要考虑系统的规模和复杂性。
如果系统较小且功能简单，可以选择简单的架构模式，如分层架构模式。
而对于大型系统或复杂系统，更适合选择更高级的架构模式，如微服务架构模式。
其次，要考虑系统的可维护性和可扩展性。
如果系统需要经常进行修改和扩展，那么选择松散耦合的架构模式，如MVC架构模式或微服务架构模式，可以更方便地进行系统的修改和扩展。
另外，还要考虑团队成员的技术背景和熟悉度。
团队成员对于某种架构模式是否熟悉和了解，以及是否具备相应的技术能力，也是选择合适的架构模式的考虑因素之一。
理解软件架构模式的优劣与适用场景
理解软件架构模式的优劣与适用场景在软件开发的过程中，选择适合的软件架构模式对于项目的成功至关重要。
软件架构模式可以看作是一种设计模式，它定义了软件系统的基本结构和交互方式，能够帮助开发人员解决各种复杂性和灵活性的问题。
本文将介绍几种常见的软件架构模式，分析它们的优劣以及适用场景。
一、层次式架构模式层次式架构模式是一种将应用程序划分为多个逻辑层次，每个层次都有特定的功能的模式。
这些层次通常包括展示层、业务逻辑层和数据访问层。
这种模式的优点是结构清晰、易于维护和扩展。
每个层次可以独立变更，不会对其他层次产生影响。
然而，层次太多会导致过度复杂，增加了系统的开销和维护成本。
适用于对系统可扩展性要求较高的场景。
二、客户-服务器模式客户-服务器模式是一种将应用程序划分为客户端和服务器端的模式。
客户端负责用户界面和用户交互，而服务器端负责处理业务逻辑和数据存储。
这种模式的优点是易于维护和扩展，客户端可以在不触及服务器端代码的情况下进行升级和更新。
然而，由于客户端和服务器端之间需要进行通信，所以必须考虑网络延迟和可靠性的问题。
适用于分布式系统和需要大量用户终端的场景。
三、发布-订阅模式发布-订阅模式是一种通过定义发布者和订阅者来实现异步消息传递的模式。
发布者负责产生消息并将其发送给订阅者，订阅者可以选择性地接收感兴趣的消息。
这种模式的优点是解耦性强，发布者和订阅者之间没有直接的依赖关系。
缺点是在高并发场景下可能导致消息堆积和处理延时的问题。
适用于需要实现解耦和异步处理的场景。
四、微服务架构模式微服务架构模式是一种将应用程序划分为多个小型服务的模式，每个服务都独立运行，并通过通信协议进行交互。
这种模式的优点是每个服务可以独立开发和部署，容错性强，易于扩展和维护。
然而，微服务的拆分和通信会增加系统的复杂性，也会引入一些分布式系统的问题。
适用于大型复杂系统和需要高度可伸缩性的场景。
五、事件驱动架构模式事件驱动架构模式是一种基于事件和消息传递的模式，系统中的各个组件通过发布和订阅事件进行通信。
八种架构设计模式及其优缺点
八种架构设计模式及其优缺点八种架构设计模式及其优缺点概述(上)1. 什么是架构我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。
哈哈，我理解，架构就是骨架，如下图所示：人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。
架构对于软件的重要性不亚于骨架对人类身体的重要性。
2. 什么是设计模式这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。
作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。
总体而言，共有八种，分别是：1. 单库单应用模式：最简单的，可能大家都见过2. 内容分发模式：目前用的比较多3. 查询分离模式：对于大并发的查询、业务4. 微服务模式：适用于复杂的业务模式的拆解5. 多级缓存模式：可以把缓存玩的很好6. 分库分表模式：解决单机数据库瓶颈7. 弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一8. 多机房模式：解决高可用、高性能的一种方法3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。
虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。
缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。
4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。
各种组织结构的优缺点
各种组织结构的优缺点组织结构是指一个企业或组织的内部架构和管理方式，它影响着组织的运作效率和灵活性。
在各种组织结构中，每一种都有其独特的优势和劣势。
下面将介绍常见的几种组织结构，包括功能型、分工型、矩阵型、混合型和平坦型。
1.功能型组织结构：功能型组织结构是最简单和常见的一种组织结构，它按照企业的职能划分不同的部门。
优点是职责明确，任务分工清晰，有利于资源的专业化配置和对各项活动的控制。
然而，功能型组织结构也存在缺点，如沟通效率低下，联动困难，不利于整合各部门之间的协作。
2.分工型组织结构：分工型组织结构是按照产品线或地区进行划分，将不同产品线或地区的管理责任独立分配给各自的部门。
优点是便于各个部门之间的协调和沟通，提高了整体运作效率。
然而，分工型组织结构也存在问题，如过度分散权力导致信息孤岛，困扰决策效率。
3.矩阵型组织结构：矩阵型组织结构将职能型和分工型组织结构的特点相结合，同时注重职能部门和项目部门的协调。
优点是促进了跨部门的协作和信息共享，提高了决策效率和创新能力。
然而，矩阵型组织结构也面临着复杂的沟通和决策机制，容易造成权力争夺和冲突。
4.混合型组织结构：混合型组织结构是根据不同的要素进行组合，根据实际情况与需求来制定组织结构，灵活性较高。
优点是可以根据具体情况对各个部门进行灵活配置和调整，使组织更加适应外部环境的变化。
然而，混合型组织结构的问题是较难把握各要素之间的关系，需要强大的管理能力来协调各部门之间的冲突。
5.平坦型组织结构：平坦型组织结构是一种去中心化的组织形式，强调交叉功能，没有明确的层级结构和权力集中。
优点是鼓励员工的主动性和创造力，加强团队协作和灵活性。
然而，平坦型组织结构也存在缺点，如决策过程可能较慢，缺乏明确的权责界定，易导致混乱和不确定性。
综上所述，不同的组织结构都有其特点和适应的环境。
企业和组织应根据自身的需求和目标，选择适合自己的组织结构，并灵活调整和改进。
同时，要注意组织结构的优化和，以适应不断变化的外部环境和市场竞争的需要。
各种不同的组织结构各有些什么优点和缺点
各种不同的组织结构各有些什么优点和缺点？何种企业适合用何种组织机构？直线制最简单和最基础的组织形式。
它的特点是企业各级单位从上到下实行垂直领导，呈金字塔结构。
直线型组织结构中下属部门只接受一个上级的指令，各级主管负责人对所属单位的一切问题负责。
直线型组织结构是最古老的组织结构形式。
所谓的“直线”是指在这种组织结构下，职权直接从高层直线型组织结构优点：管理结构简单，管理费用低，命令统一，决策迅速，责任明确，指挥灵活，上下级关系清楚，维护纪律和秩序比较容易。
缺点：管理工作简单粗放，成员之间和组织之间横向联系差。
职能制优点：这种模式是在维持职能制的同时，针对特定的核心过程组建一个管理小组，负责跨职能部门的协调。
这个小组通常设在综合的参谋部门，或作为一个新的参谋部门出现。
缺点：它对于业务过程有有限的控制权，它要通过说服和谈判来协调部门之间的活动。
事业部制优点：由于实行分权，各部门的责任比较清楚，有利于缩短解决问题的时间；事业部组织可以按照不同产品、地区划分，具有较强的独特性。
缺点：各事业部重复拥有相同的经营职能，造成经营资源上的浪费；由于受组织之间的限制，难以产生跨越不同事业部的新产品、新服务；短期利益取向较强，不容易制定和实施有利于中长期利益的对策。
矩阵制优点：能促进各部门、各层经理的合作与协调，在保持专业分工的同时加强联系和沟通；有利于把管理职能，产品的产销及地区市场因素综合起来加以考虑，为实现共同的利润目标合理配置资源。
缺点：多重领导易导致低效率；协调不当易在经理之间产生矛盾。
项目制项目团队是为了某个特定的业务目标，在一段特定的时间内组建的临时跨职能团队。
优点：该模式对于实现特定的目标是非常有效的。
此外，还有助于激发集体的创造性，如在一些产品开发项目中的情形。
缺点：当团队解散、成员回到原部门时，团队所执行项目过程中形成的关于过程的知识（一个项目的全过程的相关知识）就容易丢失；另外，团队成员的职业发展也不能得到有效的保证。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
八种架构设计模式及其优缺点概述(上)1. 什么是架构我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。
哈哈，我理解，架构就是骨架，如下图所示：人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。
架构对于软件的重要性不亚于骨架对人类身体的重要性。
2. 什么是设计模式这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。
作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。
总体而言，共有八种，分别是：1.单库单应用模式：最简单的，可能大家都见过2.内容分发模式：目前用的比较多3.查询分离模式：对于大并发的查询、业务4.微服务模式：适用于复杂的业务模式的拆解5.多级缓存模式：可以把缓存玩的很好6.分库分表模式：解决单机数据库瓶颈7.弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一8.多机房模式：解决高可用、高性能的一种方法3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。
虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。
缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。
4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。
这种模式的一般设计见下图：如上图所示，这种模式较单库单应用模式多了一个CDN、一个云存储OSS(七牛、又拍等雷同)。
一个典型的应用流程(以用户上传、查看图片需求为例)如下：1.上传的时候，用户选择本地机器上的一个图片进行上传2.程序会把这个图片上传到云存储OSS上，并返回该图片的一个URL3.程序把这个URL字符串存储在业务数据库中，上传完成。
4.查看的时候，程序从业务数据库得到该图片的URL5.程序通过DNS查询这个URL的图片服务器6.智能DNS会解析这个URL，得到与用户最近的服务器(或集群)的地址A7.然后把服务器A上的图片返回给程序8.程序显示该图片，查看完成。
由上可知，这个模式的关键是智能DNS，它能够解析出离用户最近的服务器。
运行原理大致是：根据请求者的IP得到请求地点B，然后通过计算或者配置得到与B最近或通讯时间最短的服务器C，然后把C的IP地址返回给请求者。
这种模式的优缺点如下：优点：资源下载快、无需过多的开发与配置，同时也减轻了后端服务器对资源的存储压力，减少带宽的使用。
缺点：目前来说OSS，CDN的价格还是稍微有些贵(虽然已经降价好几次了)，只适用于中小规模的应用，另外由于网络传输的延迟、CDN的同步策略等，会有一些一致性、更新慢方面的问题八种架构设计模式及其优缺点概述(中)2017-03-31码农原创码农原创码农原创文章，适合程序员、工程师、架构师等一切与软件开发相关的工作者阅读在上篇文章中，介绍了八种架构设计模式中的两种，既：单库单应用模式、内容分发模式，没有读过的同学请手动微信关注“码农原创”公众号，在历史消息中寻找。
接下来继续介绍三种架构模式，分别是：查询分离模式、微服务模式、多级缓存模式。
1. 查询分离模式这种模式主要解决单机数据库压力过大，从而导致业务缓慢甚至超时，查询响应时间变长的问题，也包括需要大量数据库服务器计算资源的查询请求。
这个可以说是单库单应用模式的升级版本，也是技术架构迭代演进过程中的必经之路。
这种模式的一般设计见下图：如上图所示，这种模式较单库单应用模式与内容分发模式多了几个部分，一个是业务数据库的主从分离，一个是引入了ES，为什么要这样？都解决了哪些痛点，下面具体结合业务需求场景进行叙述。
场景一：全文关键词检索我想这个需求，绝大多数应用都会有，如果使用传统的数据库技术，大部分可能都会使用like这种SQL语句，高级一点可能是先分词，然后通过分词index相关的记录。
SQL语句的性能问题与全表扫描机制导致了非常严重的性能问题，现在基本上很少见到。
这里的ES是ElasticSearch的缩写，是一种查询引擎，类似的还有Solr 等，都差不多的技术，ES较Solr配置简单、使用方便，所以这里选用了它。
另外，ES支持横向扩展，理论上没有性能的瓶颈。
同时，还支持各种插件、自定义分词器等，可扩展性较强。
在这里，使用ES不仅可以替代数据库完成全文检索功能，还可以实现诸如分页、排序、分组、分面等功能。
具体的，请同学们自行学习之。
那怎么使用呢？一个一般的流程是这样的：1.服务端把一条业务数据落库2.服务端异步把该条数据发送到ES3.ES把该条记录按照规则、配置放入自己的索引库4.客户端查询的时候，由服务端把这个请求发送到ES，得到数据后，根据需求拼装、组合数据，返回给客户端实际中怎么用，还请同学们根据实际情况做组合、取舍。
场景二：大量的普通查询这个场景是指我们的业务中的大部分辅助性的查询，如：取钱的时候先查询一下余额，根据用户的ID查询用户的记录，取得该用户最新的一条取钱记录等。
我们肯定是要天天要用的，而且用的还非常多。
同时呢，我们的写入请求也是非常多的，导致大量的写入、查询操作压向同一数据库，然后，数据库挂了，系统挂了，领导生气了，被开除了，还不起房贷了，露宿街头了，老婆跟别人跑了，......不敢想，所以要求我们必须分散数据库的压力，一个业界较成熟的方案就是数据库的读写分离，写的时候入主库，读的时候读从库。
这样就把压力分散到不同的数据库了，如果一个读库性能不行，扛不住的话，可以一主多从，横向扩展。
可谓是一剂良药啊！那怎么使用呢？一个一般的流程是这样的：1.服务端把一条业务数据落库2.数据库同步或异步或半同步把该条数据复制到从库3.服务端读数据的时候直接去从库读相应的数据比较简单吧，一些聪明的、爱思考的、上进的同学可能发现问题了，也包括上面介绍的场景一，就是延迟问题，如：数据还没有到从库，我就马上读，那么是读不到的，会发生问题的。
对于这个问题，各家公司解决的思路不一样，方法不尽相同。
一个普遍的解决方案是：读不到就读主库，当然这么说也是有前提条件的，但具体的方案这里就不一一展开了，我可能会在接下来的分享中详解各种方案。
另外，关于数据库的复制模式，还请同学们自行学习，太多了，这里说不清。
该总结一下这种模式的优缺点的了，如下：优点：减少数据库的压力，理论上提供无限高的读性能，间接提高业务(写)的性能，专用的查询、索引、全文(分词)解决方案。
缺点：数据延迟，数据一致性的保证。
2. 微服务模式上面的模式看似不错，解决了性能问题，我可以不用露宿街头了、老婆还是我的，哈哈。
但是软件系统天生的复杂性决定了，除了性能，还有其他诸如高可用、健壮性等大量问题等待我们解决，再加上各个部门间的撕逼、扯皮，更让我们码农雪上加霜，所以继续吧......微服务模式可以说是最近的热点，花花绿绿、大大小小、国内国外的公司都在鼓吹，实践这个模式，可是大部分都没有弄清楚为什么要这么做，也并不知道这么做有什么好处、坏处，在这里，我将以我自己的亲身实践说一下我对这个模式的看法，不喜勿喷！随着业务与人员的增加，遇到了如下的问题：1.单机数据库写请求量大量增加，导致数据库压力变大2.数据库一旦挂了，那么整个业务都挂了3.业务代码越来越多，都在一个GIT里，越来越难以维护4.代码腐化严重、臭味越来越浓5.上线越来越频繁，经常是一个小功能的修改，就要整个大项目要重新编译6.部门越来越多，该哪个部门改动大项目中的哪个东西，撕逼的厉害7.其他一些外围系统直接连接数据库，导致一旦数据库结构发生变化，所有的相关系统都要通知，甚至对修改不敏感的系统也要通知8.每个应用服务器需要开通所有的权限、网络、FTP、各种各样的，因为每个服务器部署的应用都是一样的9.作为架构师，我已经失去了对这个系统的把控......为了解决上述问题，我司使用了微服务模式，这种模式的一般设计见下图：如上图所示，我把业务分块，做了垂直切分，切成一个个独立的系统，每个系统各自衍化，有自己的库、缓存、ES等辅助系统，系统之间的实时交互通过RPC，异步交互通过MQ，通过这种组合，共同完成整个系统功能。
那么，这么做是否真的解决上述问题了呢？不玩虚的，一个个来说。
对于问题一，由于拆分成了多个子系统，系统的压力被分散了，而各个子系统都有自己的数据库实例，所以数据库的压力变小。
对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会所有的功能不可用，从而解决一个数据库挂了，导致所有功能不可用的问题。
问题三、四，也因为拆分得到了解决，各个子系统有自己独立的GIT代码库，不会相互影响。
通用的模块可通过库、服务、平台的形式解决。
问题五，子系统A发生改变，需要上线，那么我只需要编译A，然后上线就可以了，不需要其他系统做同样的事情。
问题六，顺应了康威定律，我部门该干什么事、输出什么，也通过服务的形式暴露出来，我部只管把我部的职责、软件功能做好就可以。
问题七，所有需要我部数据的需求，都通过接口的形式发布出去，客户通过接口获取数据，从而屏蔽了底层数据库结构，甚至数据来源，我部只需保证我部的接口契约没有发生变化即可，新的需求增加新的接口，不会影响老的接口。
问题八，不同的子系统需要不同的权限，这个问题也优雅的解决了。
问题九，暂时控制住了复杂性，我只需控制好大的方面，定义好系统边界、接口、大的流程，然后再分而治之、逐个击破、合纵连横。
目前来说，所有问题得到解决！bingo!但是，还有许多其他的副作用会随之产生，如RPC、MQ的超高稳定性、超高性能，网络延迟，数据一致性等问题，这里就不展开来讲了，太多了，一本书都讲不完。
另外，对于这个模式来说，最难把握的是度，切记不要切分过细，我见过一个功能一个子系统，上百个方法分成上百个子系统的，真的是太过度了。
实践中，一个较为可行的方法是：能不分就不分，除非有非常必要的理由！。
优点：相对高性能，可扩展性强，高可用，适合于中等以上规模公司架构。
缺点：复杂、度不好把握。
指不仅需要一个能在高层把控大方向、大流程、总体技术的人，还需要能够针对各个子系统有针对性的开发。