三层架构和MVC是当前两大主流开发模式。
 
三层架构相对容易掌握，在业务类为主的项目中应用，可以做到快速实现。
MVC架构相对复杂些，开发者需要考虑除了业务外的更多其他包括用户体验，用户安全和实体类设计的资源配置。
 
认为技术上讲，MVC需要掌握的内容更全面，要花的精力比三层架构的要多谢，作品更专业化。

作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
今天介绍下组件化开发方面的内容，在前面我讲解微服务的时候就已经谈到，实际上微服务本身就是传统的业务系统组件化开发的一个升级。懂得基础的组件化开发和技术架构设计是也是过渡到当前主流的微服务架构思想的基础。
组件化开发概述
在这里先介绍和说明下基于组件化开发带来的优势。
首先，原有到系统级的粗粒度控制细化到了组件级别的细粒度控制，一个复杂系统的构建就是组件最终集成后的一个结果。每个组件都自己独立的版本，组件可以独立编译、独立打包和部署；
其次，产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售，用户可以选择购买哪些组件，组件之间可以灵活的进行组装。另外，包括诸如配置管理、开发、测试、打包、发布完全控制到组件层面，会带来其它很多好处，如果一个组件进行小版本升级，提供给外部的接口没有任何变动，其它组件完全可以不用做任何测试。
组件化开发思路在SOA之前已经有成熟的组件化开发方法，只是在SOA出现后，SOA咨询、需求分析、设计实现方法论进一步融入到组件化开发中。各种底层基础技术框架的发展和完善，为组件化开发提供了根据完整的支持，推动组件化开发的发展，特别是在B/S架构下的组件化开发。
回到软件生命周期，我们再来阐述下组件化开发的核心思路和逻辑。
业务建模和业务组件阶段
流程驱动IT以及SOA思想的进一步融合，再次改变原有的组件开发重点关注技术组件层面的问题。业务建模阶段重点包括了业务架构和数据架构，其导入点仍然是端到端流程分析为主线导入。业务架构分析重点就是形成业务组件，也可以叫业务模块。
在这里重点还是业务组件的形成，要知道业务组件来源于流程分析和流程分解。业务组件本身就是高度内聚的多个业务功能的一个集合，业务组件之间本身就是松耦合，业务组件通过交互和集成可以完成一个更大的端到端流程。业务组件的识别仍然回归传统的流程分析加面向结构下面的CRUD矩阵分析等方法来分析高内聚性。矩阵分析包括了业务功能和业务数据之间的CRUD关系，也包括了业务功能和业务功能之间本身的关联和依赖性分析。
对于粗粒度的数据建模我们把它划归到业务建模阶段，该阶段的数据建模偏概念模型，后续在设计阶段再转化到物理模型和数据实体组件。同时该阶段的数据建模需要梳理出业务和流程中核心的基础主数据和核心业务单据，分析业务单据关联映射关系，协助前面谈到的CRUD矩阵分析。
在这个阶段最终需要输出的涉及到组件层面的产出物包括软件系统的业务组件，每个业务组件包含的业务功能或叫业务用例。整个业务系统中的业务实体，业务实体关系图等。
软件需求阶段
在这个阶段不做详细的说明，但是我们仍然需要理顺整个关系，即首先形成业务组件，业务组件是大的业务模块。业务组件下面有业务用例，这里的业务用例通过进一步的需求分析和开发，将业务用例转换为系统用例，然后对每一个系统用例进行详细的描述。业务流程-》业务组件-》系统用例是一个从上向下，逐层展开的一个分析过程。
在传统的用例建模中，我们没太关注用例之间的交互，而将其延后到设计和实现阶段去完成。现在来看该工作需要提前，即从全系统来看，首先完成对业务组件之间交互的描述，对交互点和交互场景进行详细说明。在细化进入到一个业务组件内部后，需要对系统用例之间的相互调用进行描述。
对于数据层面则在软件需求阶段进一步细化，从概念模型阶段过渡到逻辑模型阶段，进一步细化业务功能为系统操作，分析系统操作和数据对象之间的关系。
系统建模和技术组件阶段
这个阶段即传统的架构设计阶段，我们仍然是组件化开发的一个重点，这里的系统建模和架构设计重点都变化为功能性架构。但是前面业务建模阶段已经有前期的积累。如果是业务建模阶段是系统分析的话，那么系统建模阶段是系统设计。
系统建模阶段第一个重点是要实现从业务组件到技术组件的细化。在前述对SOA的分析中我们提到业务组件、服务组件和技术组件。在这里我们只谈业务组件和技术组件，并弱化服务组件的概念。首先，进入了架构分层后，一个业务组件可能需要拆分为多个技术组件，包括数据层组件、逻辑层组件、UI层组件、数据实体组件等。其次，在该阶段我们会引入很多的纯技术层面的组件，这些技术层面组件和业务完全无关而和平台非功能性架构有关，如安全、异常、日志等相关组件等。
业务组件本身符合高内聚性，转换到技术组件后仍然需要符合高内聚性，技术组件之间其一不允许出现相互交叉调用；其二整个调用关系应该是从上层往下层调用。纵向看是UI组件->逻辑层组件->数据层组件调用关系；而横向看则是同层之间的各个技术组件之间存在相互调用关系。按照组件最大化复用原则，优先考虑UI组件复用，其次考虑逻辑层复用，最后才考虑数据层复用。
根据前面分析可以很明显的看到在系统建模阶段关于组件分析和设计的几个重点内容：其一是业务组件转换为技术组件，并按层分解；其二是根据业务交互，用例交互分析组件之间的调用关系。这些调用关系就是组件间的接口，通过业务和流程分析的方法来找到接口，转到相关组件的接口设计上，组件之间的调用只能通过接口，组件内部完全黑盒；其三是数据建模和设计，将前面数据建模分析内容转换为数据实体组件，数据实体组件只含数据实体，实现控制类和实体类的分离。这样数据实体类容易变化为下层可以被多个逻辑层技术组件引用的组件。
这个阶段在传统的架构设计文档上，可以看到需要输出的内容包括了业务组件->技术组件的对应清单，组件调用关系和依赖关系图，组件接口设计文档和接口清单，可复用组件抽取和分析，组件包视图和部署视图，整个应用系统的组件化后的产品结构视图和配置项清单等。
实现阶段
实现阶段我们关注的问题是一个技术平台或框架支持组件化开发、测试和部署。传统的B/S架构开发我们比较难以解决的问题是UI层内容的独立打包和部署，而当前在新的微服务架构和前后端分离开发框架下，已经可以完全做到前端和后端单独打包和部署。
可以单独对组件进行自动化的单元测试，当某个组件有变化的时候，可以单独对变化的组件进行版本升级，单独对变化组件进行部署。整个产品的版本由应用系统管理到里面的每个组件，这些都将是发生变化的点。
业务架构设计
业务架构设计是定义和识别业务组件的基础。对于业务架构的设计需要遵循企业架构方法论中业务流程分析思路，借鉴IBM的CBM组件化的业务模型建模思路。
业务架构是一个纯粹意义上的业务概念，只关心具体的业务域和业务功能。业务架构可以看做由多个高内聚、低耦合的业务组件构成，因此在业务架构完成后基本就确定了业务组件的划分方法和粒度等问题。
业务组件的划分需要和业务架构图对应，可以将业务架构图中的每个业务模块识别和定义为一个业务组件，也可以根据高内聚、低耦合准则将多个业务模块合并为一个业务组件。以采购管理业务域为例，经过前期的流程分析和业务交互矩阵分析，得出如下的业务架构图：
进一步基于业务高内聚的思想，可以将采购管理业务划分为招投标管理、采购管理、基础数据管理、采购绩效分析等多个业务组件并指导后续的组件设计和开发。
比如我们基于价值链已经看到供应链跨越流程，那么我们可以对供应链流程进行梳理。
梳理完后你会发现，输出的职能带流程图中的大阶段刚好就是你业务架构里面的业务域或业务单元。或者流程图中的业务活动刚好就是你业务架构分解到最底层的业务功能模块。
即当我们流程分析到最底层后，我们就可以抽象输出一个最底层的业务架构图。比如对应供应链和采购管理，我们可以输出到最底层的业务架构图或业务组件图。
逻辑架构设计
对于应用层的逻辑架构仍然参考平台+服务+应用分层的思路，对于新平台架构下应用必须结合平台层和服务能力才能组装成为一个传统的完整应用。对于应用层而言，其中仍然分为数据层、业务逻辑层和展现层的三层架构模式：
数据层
数据层主要包括了对于主数据等共享数据的访问和读取，也包括了对业务组件模块自己私有数据的CRUD操作。数据层可以直接调用DaaS服务层能力操作底层数据库，也可以直接调用封装后的领域数据服务能力查询和访问数据。
业务逻辑层
业务逻辑层和传统业务逻辑层最大的区别是体现了SOA服务化的思想。即对于业务流程和功能的业务实现是通过平台层提供的技术服务和业务服务能力进行组合和组装实现的。这既可以通过传统的代码开发和服务调用来实现，也可以通过类似BPEL设计和建模工具等可视化的进行灵活配置和实现。
前端展现层
展现层主要是各种前端和界面实现技术，包括了JSP，HTML和现在主流的VUE, React框架等。展现层通过调用逻辑层的服务能力进行数据的存取和业务规则的实现，同时也包括了界面集成技术实现多个业务组件的界面集成。
技术架构设计
对于应用技术架构设计，主要还是参考传统的分层架构模式，结合SOA和组件化思想进行调整，其中重点是业务逻辑层和Web层两方面的内容的细化：
业务逻辑层
业务逻辑层本质是提供业务服务能力的服务组件层，其中包括了数据访问层，内部的技术组件，内部的服务接入软总线，外部的服务代理实现服务接入和服务发布。业务逻辑层最终的业务能力将以内部软总线的方式提供给Web层使用。
Web容器层和界面展现
该层的重点是实现标准的MVC模式。对于来自前端界面应用的请求信息先经过控制器处理后转给模型处理再进行视图层面输出，以实现界面显示和数据处理的分离。如通过Java的Struts框架来实现标准的MVC模式等。
集成架构设计
业务组件以 Web 服务的方式提供接口，通过企业服务总线连接。业务组件内部为了实现高可复用性和高效性，采用基于 OSGi 内部软总线标准进行构建模块，实现内部模块之间的松耦合。即在业务组件内部基于 OSGi 标准进行模块化设计，将业务组件进一步分解为松耦合的模块(Bundle)，使得业务组件本身更加灵活。
基于 OSGi 标准，业务组件内部的模块通过一个具有动态加载类功能的微内核连接，统一管理各个模块。为了便于管理，将不同模块之间的类接口采用服务注册的方式进行管理，具有类动态加载功能的微内核和类接口管理组成类总线(JCB)的基本功能；为了更好的实现重用，有些模块是共用的，比如数据访问模块、日志管理模块等。
服务软总线
实现一个业务组件内部的服务注册、调用和服务管理，一般采用比较轻量的如OSGi标准来实现。软总线机制可以保证业务组件内部的进一步松耦合设计。
注：在当前微服务架构下，我们看到实际上组件之间的接口集成，已经不再需要类似OSGI这种内部软总线，而是直接采用去中心化的服务注册中心来完成集成工作。
服务组件和技术组件
服务组件是业务组件中唯一和外部进行交互的接口组件，包括了服务消费和服务调用均在服务组件完成。技术组件为服务组件的具体实现，内部功能的业务规则实现等。
服务代理
服务代理包括了服务消费代理和服务发布代理。业务组件本身要消费外部的服务，包括技术服务、流程服务和其它业务组件提供的业务服务，这些通过服务消费代理来完成。同时业务组件本身也需要向外部其它业务组件提供可复用的业务服务能力，因此需要将内部的服务接口进一步通过服务发布代理，发布为外部可访问的业务服务并注册到外部ESB服务总线上。
组件间整体框架集成
业务组件本身就是一个能够提供独立业务价值能力的小应用系统。组件的集成包括了组件的纵向集成和横向集成。组件的纵向集成即和PaaS平台技术服务能力的集成，通过集成后形成一个完整的应用。横向集成则是流程驱动的业务组件之间通过业务服务的横向协同和集成，通过横向集成加上和外层应用框架和门户的集成后，多个业务组件将构成传统的完整业务系统。
应用框架集成
在企业私有云PaaS平台的建设过程中，虽然基于平台+应用和SOA组件化架构思想真正实现了高复用和对业务的灵活应变能力，但是一个传统完整的业务系统已经被分解到了平台，服务和应用多个层面的技术组件，业务组件和服务中。因此这些分散的组件如何最终集成和还原为一个传统意义上完整的业务系统将成为应用集成必须考虑的重点内容。
结合实践经验，最好方式是通过门户+外层应用框架来实现总体的集成，具体参考：
以上图为例来看一个完整的业务系统。除了白色部分外，其余的组成部分都应该是有平台层统一规划建设和提供。应用外层框架和组件动态装载是重新还原一个传统意义上的业务系统的集成。应用外层框架首先是需要和门户进行集成，实现基本的统一认证和单点登录；其次是读取系统管理的基本参数和配置信息，实现外层界面和菜单资源等的装载和初始化；最后是根据应用配置文件灵活的对PaaS平台层的技术组件(系统管理，流程引擎)，应用层的业务组件进行动态装载。
应用外层UI界面框架需要基于可重用，可配置的思想独立开发，该框架是一个包括了菜单描述文件，页面描述文件，工具栏描述文件，页面布局描述文件组成一个基本的页面框架，具体说明如下。
欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设。

前言
 
Mysql作为目前互联网工作的主流数据库，有着其不容撼动的地位，之前面试过一些公司，对于程序员来说，企业对于Mysql的技能要求还是比较高的。所以有必要系统深入研究下Mysql。于是乎就有了这一系列博客的诞生。这些博客内容主要是结合我自己工作中所用的的东西，以及《高性能Myql》这本书的读书笔记。
 
 
购买地址
 
，请支持正版图书。
 
1.1、Mysql逻辑结构
  
Mysql是三层的逻辑架构，如下图
 
第一层：服务层(为客户端服务):为请求做连接处理，授权认证，安全等。
 
第二层：Mysql核心服务层：主要提供，查询解析、分析、优化、缓存以及内置函数，跨存储引擎功能(存储过程、视图、触发器)
 
第三层：存储引擎层，负责数据的存储和提取
 
1.1.1、连接管理与安全性
 
这里有第一层处理，每个客户端的连接都会在服务器进程中拥有一个线程，连接的查询在这个线程中单独进行。
 
1.1.2、优化与执行
 
此处由第二层，中间层处理，该处的优化器负责创建内部数据结构，然后优化，包括重写查询，决定表的读取顺序，以及选择合适的索引。
 
1.2、并发控制
 
并发是个老生常谈的问题，不管在java还是mysql以及oracle中，都需要保证并发时数据的一致性。面对并发问题，不可避免的都需要用到锁，并发的优化很多时候也就是锁的优化。
 
1.2.1、读写锁
  
读锁：共享，互不阻塞，即多用户同一时刻读统一资源，互不干扰。
 
写锁：排他，一个写锁会阻塞其他的读和写，安全策略只有这样才能保证同一时刻只有一个用户能写入，并防止其他用户读取正在写入的同一资源，避免脏读。
 
1.2.2、锁力度
 
一种优化的策略，对于不同的锁提供不同的力度，让锁定对象更有选择性。当然加锁的操作也增加系统的开销。包括(获得锁，检查锁是否解除，是否锁)。下面介绍两种最重要的锁力度
  
表锁(table lock) 顾名思义就是将整张表锁定，Mysql中最基本的锁策略，并且是开销最小的策略，加锁之后，整个表数据受到影响，不利于并发，写锁优先级高于读锁，因此一个写锁请求可能会被插入到读锁的队列前面。服务器也会使用ALTER TABLE之类的语句使用表锁。
 
行级锁(row lock) 支持高并发，同事带来最大的锁开销。只有存储引擎实现，第二层不会实现。
 
1.3、事务
 
事务也是数据库中一个老生常谈的问题，我们常常口头说的ACID，或者可以说是一个独立的工作单元，对外只有成功和失败的结果，不会出现部分成功或者失败。也即提交(commit)或者回退(rollback)两种操作。
  
A(Atomicity-原子性)：不可分割的单元，要么成功，要么失败。
 
C(Consistency-一致性)：主要强调的是，如果在执行事务之前数据库是一致的，那么在执行事务之后数据库也还是一致的
 
I(Isolation-隔离性)：事务彼此之间没有影响，即在最终提交前对其他事务不可见
 
D(Durability-持久性)：一旦事务提交，其修改会永久保存到数据库中。
 
不是所有的数据库都支持事务，像现在大火的nosql大多都不支持事务，而mysql不同的引擎对事务的支持也不一样，像默认的InnoDB是支持事务的，而Myisam这一的引擎就不支持事务。这个需要根据业务去做相应的选择
 
1.3.1、隔离级别
  
数据库提供了四种事务隔离级别, 不同的隔离级别采用不同的锁类开来实现.
 
隔离级别
 
脏读可能性
 
不可重复读可能性
 
幻读可能性
 
加锁读
  
READ UNCOMMITTED YES YES YES NO 
 
READ COMMITED NO YES YES NO 
 
REPEATABLE READ NO NO YES NO 
 
SERIALIZABLE NO NO NO YES 
 
相关概念
  
脏读：事务中的修改，即使未提交，对其他事务也是课件的。事务可以读取未提交的数据。
 
不可重复读：在同一个事务中，再次读取数据时，所读取的数据，和第1次读取的数据，不一样了
 
幻读：幻读的重点在于新增或者删除，同样的条件, 第1次和第2次读出来的记录数不一样。幻读是指当一个事务在读取某个范围内的数据时，另一个事务在这个范围内插入了一行记录并提交，于是当前一个事务再次读取该范围内的数据时，发现多出了一行，即幻行。
 
脏读、不可重复读、幻读的级别高低是： 脏读 < 不可重复读 < 幻读所以，设置了最高级别的SERIALIZABLE_READ就不用在设置REPEATABLE_READ和READ_COMMITTED了
 
READ UNCOMMITTED(未提交读)：数据库中几乎不用这种事务。
 
READ COMMITED(已提交读)：大多数数据库的默认隔离级别(MySQL不是)。这个级别代表事务开始后，只能读到其他事务提交后的修改，未提交的修改是不可见的。显然这样就解决了脏读的问题。但是还是会遇到不可重复读的问题。
 
REPEATABLE READ(可重复读)：Mysql的默认隔离级别，该级别保证了同一个事务中多次读取同样记录的结果是一致的。
 
SERIALIZABLE(可序列化读)：最高的隔离级别，通过强制事务串行执行，避免了前面说的幻读问题。该级别会在读取的每一行上都加锁，所以可能导致大量的超时和锁争用问题。
 
1.3.2、死锁
 
两个活多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。为解决这种问题，数据库都是些了各种死锁检测和死锁超时机制。
  
如InnoDB若检测到死锁循环依赖，就立即返回一个错误。
 
当查询时间到锁等待超时的设定后放弃锁清秋。InnoDB的处理方式是，将持有最少行级排他锁的事务进行回滚。
 
1.4、事务日志
 
由于事务日志的写入是顺序I/O操作，会比随机I/O快的多。(因为机械硬盘读写最费时间的就是磁头的定位和移动过程) 当数据持久化到事务日志以后，再慢慢地刷写回真正的数据库。即使途中服务器挂了，重启后还是可以根据事务日志来恢复数据。
 
1.5、MySQL中的事务
 
MySQL提供了两种事务的存储引擎：InnoDB和NDB cluster。另外还有一些第三方的事务，比较知名的有XtraDB和PBXT。
  
自动提交(AutoCommit)：Mysql默认是自动提交模式。如果你不显式地开始一个事务，那么每次查询都当做一个事务。可通过以下方式查询活修改自动提交模式
 
SHOW VARIABLES LIKE 'AUTOCOMMIT';
 
 
SET AUTOCOMMIT = 0;--1表示启用，0表示禁用
 
设置隔离级别：可以配置文件中修改整个数据库的隔离级别，也可以只改变当前会话的隔离
 
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
 
1.6、多版本并发控制(MVCC)
 
不同的存储引擎MVCC实现不同，典型的有乐观并发和悲观并发控制。下面结合InnoDB说明下。InnoDB的MVCC，通过在每行记录后面保存两个隐藏列实现，这两个列一个保存行的创建时间，一个保存过期(删除时间)，当然这里存储的创建时间不是真正的时间，而是系统版本号。
  
REPEATABLE READ级别下，MVCC操作如下：
 
select ：InnoDB只查找版本早于当前事务版本的数据行(即创建版本号《=当前事务版本号)，这样保证事务读取的行是早于事务开始前就已经存在的。删除版本号》当前事务版本号，保证事情读取到的行在事务开始前未被删除。
 
insert：插入新行的时候，将事务分配到的版本号赋给创建版本号那个列属性。
 
delete：为删除的每一行保存当前系统版本号为行删除标识，即将该版本号存入删除版本号的那个列属性
 
update：实际上是新插入一条记录，然后将事务分配到的版本号赋给旧记录的删除版本号列以及新记录的创建版本号列。
 
MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。
 
1.7、MySQL存储引擎
 
查询表相关信息，命令如下
 
mysql> show table status like 'city' G*************************** 1. row *************************** Name: city //表名 Engine: InnoDB//引擎名 Version: 10 Row_format: Compact//行的格式 Rows: 600//行数，对于InnoDB，该行是估计值，其他引擎为准确值 Avg_row_length: 81//平均每行字节数 Data_length: 49152//表数据大小，byte为单位Max_data_length: 0// Index_length: 16384 Data_free: 0 Auto_increment: 601 Create_time: 2017-10-09 19:59:23 Update_time: NULL Check_time: NULL Collation: utf8_general_ci Checksum: NULL Create_options: Comment: 1 row in set (0.00 sec)
 
修改表的引擎采用如下语句：
 
ALTER TABLE city ENGINE = InnoDB;
 
下面简单介绍下相关存储引擎的优缺点
 
1.7.1、InnoDB
 
优点：Mysql当前的默认引擎，事务型引擎，用MVCC支持高并发，通过间隙锁在REPEATABLE READ级别下就能防止幻读。支持热备份。缺点：非常复杂，性能较一些简单的引擎要差一点儿。空间占用比较多。
 
1.7.2、MyISAM:
 
优点：Mysql 5.1之前版本的默认引擎。全文索引、压缩、空间函数(GIS)、并发插入、某些场景下性能很好 缺点：非事务型、不支持行锁、崩溃后数据不容易修复
 
1.7.3、Archive：
 
优点：支持高并发插入，解决不可重复读，针对高速插入和压缩做了优化的简单引擎 缺点：只支持查询和插入操作，非事务型，仅适合日志和数据采集的应用场景
 
1.7.4、CSV引擎：
 
优点：有效支持CSV格式文件的导入导出。缺点：作者没说
 
1.7.5、Memory引擎：
 
优点：用来快速地访问数据的，比MyISAM快一个数量级。支持Hash索引，因此查询操作非常快。缺点：所有数据保存在内存里，重启只留下表结构。只支持表级锁，并发能力低下。不支持BLOB或TEXT类型的列。且行长度固定，容易导致内存浪费。
 
1.7.6、NDB集群引擎：
 
作者没有细讲，后文会细讲的吧，总之就是支持建立集群。
 
1.7.7、XtraDB和PBXT等OLTP类引擎：
 
优点：可完全替代InnoDB,或者高度相似。还额外提供了一些性能优化、可测量性、操作灵活性 缺点：第三方的引擎，社区支持的存储引擎，可能不能保证质量 其实最常用的是InnoDB和MyISAM
  
相关参数对比
 
特性
 
InnoDB
 
MyISAM
 
MEMORY
 
ARCHIVE
  
存储限制(Storage limits) 64TB No YES No 
 
支持事物(Transactions) Yes No No No 
 
锁机制(Locking granularity) 行锁 表锁 表锁 行锁 
 
B树索引(B-tree indexes) Yes Yes Yes No 
 
T树索引(T-tree indexes) No No No No 
 
哈希索引(Hash indexes) Yes No Yes No 
 
全文索引(Full-text indexes) Yes Yes No No 
 
集群索引(Clustered indexes) Yes No No No 
 
数据缓存(Data caches) Yes No N/A No 
 
索引缓存(Index caches) Yes Yes N/A No 
 
数据可压缩(Compressed data) Yes Yes No Yes 
 
加密传输(Encrypted data[1]) Yes Yes Yes Yes 
 
集群数据库支持(Cluster databases support) No No No No 
 
复制支持(Replication support[2]) Yes No No Yes 
 
外键支持(Foreign key support) Yes No No No 
 
存储空间消耗(Storage Cost) 高 低 N/A 非常低 
 
内存消耗(Memory Cost) 高 低 N/A 低 
 
数据字典更新(Update statistics for data dictionary) Yes Yes Yes Yes 
 
备份/时间点恢复(backup/point-in-time recovery[3]) Yes Yes Yes Yes 
 
多版本并发控制(Multi-Version Concurrency Control/MVCC) Yes No No No 
 
批量数据写入效率(Bulk insert speed) 慢 快 快 非常快 
 
地理信息数据类型(Geospatial datatype support) Yes Yes No Yes 
 
地理信息索引(Geospatial indexing support[4]) Yes Yes No Yes 
    
在服务器中实现(通过加密功能)。在其他表空间加密数据在MySQL 5.7或更高版本兼容。
 
 
在服务中实现的，而不是在存储引擎中实现的。
 
 
在服务中实现的，而不是在存储引擎中实现的。
 
 
地理位置索引，InnoDB支持可mysql5.7.5或更高版本兼容
 
 
下一章开始MySQL基准测试，当然前几章相关的内容会相对少，这些主要是相关的介绍，让大家大致有个了解。 
 
推荐：一起了解下Java多线程基础
 
上一篇：Spring源码(一)-Spring整体架构和环境搭建
 
 
点击原文阅读更多
  

1-2  云商城架构设计
1、架构设计
  云商城采用了当前主流的微服务技术架构，微服务技术栈采用了当前主流的SpringCloud Alibaba技术栈，从接入层、网关层、服务层、数据同步、服务治理、数据处理、第三方接口多个方面进行了精心设计，技术经过了多次挑选、优中选优，最终打造了一套全网最优质的的微服务商城架构体系，解决了大型微服务电商应用中绝大多数难点、痛点问题。


2、前后端分离
  我们过去开发一套系统，前端、后端都需要协同工作，很多时候分工不明确、责任不清晰，沟通成本大幅增加。为了提升开发效率、降低沟通成本，前后端分离的模式应运而生，前后端分离的开发模式会让各组开发人员工作更专注，沟通只需要通过前期沟通好的开发文档进行开发即可。开发流程如下图：

  前后端分离项目中可以大大减轻前后端开发人员的工作量、大大提升开发效率、为了减少沟通成本我们通过SwaggerAPI文档来沟通的、那么怎么使用SwaggerAPI文档呢?我接下来继续介绍。
3、Swagger使用
3.1 在线工具
  编写Swagger接口，可以用Swagger Editor，地址：https://editor.swagger.io/

3.2 本地查看
  接口编写好了，可以导出到本地.

  为了能够更加直观来查看相关的接口，我们通过用swagger-ui展示，下载地址：https://swagger.io/tools/swagger-ui/

  Swagger UI是通过读取Swagger Edit的导出的YAML／JSON文件，来进行接口测试。Swgger UI的站点域名要和发送请求的域名一样。不然浏览器会报跨域错误。
安装


下载并且安装node.js(自行下载安装https://nodejs.org/zh-cn/)


npm install -g http-server


下载项目https://github.com/swagger-api/swagger-ui 并且解压。


进入swagger-ui文件夹。运行hs -p 500


进入http://127.0.0.1:500/dist/index.html就可以看到swagger页面了



使用

导入swagger.json文件把之前Swagger Edit导出的swagger.json文件复制到dist文件夹里面，修改index.html的url路径，改成指向swagger.json。就可以读取json文件的内容了。


访问 http://127.0.0.1:500/dist/index.html 即可

注意不要访问 http://localhost:500/dist/index.html 会出现跨域提示的问题

3.3 批量生成
  很多时候，我们没法快速开发完所有功能，但是有很多功能基本都是增删改查，我们可以利用工具先将增删改查的通用Swagger Api生成好，后面直接在对应基础上更改就可以了。 批量生成代码
链接：https://pan.baidu.com/s/15mBl5zFPRNGk5r1o2ZnLrw 
提取码：nc4q 

核心配置文件
#swagger 的路径、相对于当前项目
swaggerpath=com.bobo.swaggerui
#响应对象封装的名字RespResult
#respbean=RespResult
# 多条件收搜、默认是 /search
#search=/find
#多条件搜索+分页 默认是 /search/{page}/{size}   {size}表示路径参数
#pagesearch=/find/{page}/{size}
#生成文件的名称 默认：swagger.json
filename=goods.json
# 数据源配置
url=jdbc:mysql://192.168.100.130:3306/shop_goods
uname=root
pwd=123456
driver=com.mysql.jdbc.Driver

代码目录结构

生成商品表的json文件

生成订单表的json文件

将生成的相关json文件拷贝到swagger-ui的json目录下：

将添加的json文件在dist目录下的index.html文件中添加信息
	<div id="cgpj">
		所有项目:
		<select onchange="change(this.value)" id="pj">
			<option value="http://127.0.0.1:500/json/swagger.json">测试文件</option>
			<option value="http://127.0.0.1:500/json/goods.json">商品信息</option>
			<option value="http://127.0.0.1:500/json/order.json">订单信息</option>
		</select>
	</div>

查看效果

  这样话我们就可以很快的生成系统的相关API接口文档、方便前后端程序员的开发。特殊的接口我们只需要在此基础上修改即可。
------->> 你学会了吗？