vlambda博客
学习文章列表

凡尔赛体：很有必要让同行们知道GI的编码质量，所以在平台技术环节，也会陆续推送GI的部分内部代码。作为石油地质专业的学生，1999年以所谓的高薪进入IT业，才知自己在地大武汉的本硕期间的CODING，基本不算入门。尽管我也考取了高级程序员职业认证资格，2010年在北大方正也没有准备直接考取了系统架构认证资格，但这与真正IT业的高水准编码，完全是两条路。后面，有时间我会总结下我的代码之路。当下，自我评估下GI的编码的工业水准，是中等偏上，这与20多年的代码积累有关，与我工作后，坚持软件重用技术的持续学习，以及上海有机会研读BI底层源代码有些关系。与XGBOOST、TF等开源代码比（我现在研读这些开源，等同研读那些高水准的外文文献，过瘾），水准差的还是很多，这里面最大的原因也许与没有考上北大、清华有关（还好，我们团队有清华彭同学、北大景同学、哈工大曹同学、北理工李同学等，他们一直在帮我），但是最关键，还是缺乏系统全面的计算机应用学科的教育经历。我知道，我们这个行业有很多原意写代码也一直在写代码的像我这种石油地质专业背景的年轻同事，也包括解博士这个老同事。我很相信他们在专业算法的理解，比如没有解博士的一维盆地模拟代码，我和彭同学等就很难直接CODING三维盆地模拟代码。但是，还是都缺乏全面的工业级水准的代码训练，这需要真正融入IT职业实践才能有所提升，好在现在开源的时代，如果具备很强的研读和理解能力，也会跟上。

      后续，陆续推送专著相关章节和GI实际代码。关于整体软件架构设计和GI的核心底层代码，在我2010年的博士论文中已经系统阐述。也正是有这个基础，进入研究院后我们才可以极少的人极少的时间对标GEOX、PETROMOD这些软件来开发我们自己的同类软件。再次，我很确认的说，GI的20多年积累的代码实现，就是如下基本概念的全面体现。

1、设计模式、框架与构件（组件）

也可以认为是软件复用技术的代名词，是继面向对象技术之后新的软件分析与设计技术。软件开发过程随着信息科学技术的发展经历了结构化开发、面向对象开发、分布式面向对象开发、基于通用和领域基础构件开发等典型软件开发技术。而设计模式、框架与构件代表了上述进程中两次变革性的飞跃代名词：传统软件工程（结构化）向面向对象的软件工程（Object Oriented Software Engineering，OOSE）的飞跃；‚面向对象的软件过程向基于构件的软件过程（Component Based Software Engineering，CBSE）的过渡。（当下处于面向微服务的云化架构设计阶段）

（1）设计模式

Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。尽管Alexander说的是城市和建筑模式，但他的思想也同样适用于面向对象的软件设计与开发。设计模式就是针对面向对象系统中重复出现的设计问题，提出一个通用的设计方案，并予以系统化的命名和机动解释。围绕弹性体系结构设计、软件复用和高可靠性软件质量控制，我们从软件体系结构设计到具体对象间的关联关系设计，从网络编程到数据持久化访问，总结并应用了诸多设计模式，展示了典型面向油气E&P领域软件开发的经验共享，为不同学科的应用软件设计与开发提供了最新的借鉴。

（2）框架

也称白箱复用。即，一组相互协作的类，形成某类软件的一个可复用设计。换言之，框架将设计划分为一组抽象类，并定义它们各自的责任以及相互之间的合作，以此来指导软件体系结构级的设计，开发者通过继承框架中的类和组合其实例来定制该框架以生成特定的应用。采用框架复用技术，我们定义了基于领域基础中间件（GI）的通用应用软件框架。GI的通用应用软件框架抽象了不同领域计算服务，不同数据访问机制，甚至不同界面实现等，使得应用软件框架能够快速被实例化成不同学科的不同类型的专业应用软件。

（3）构件

也称黑箱复用。即，基于对象组合的复用模式，这些被组合的对象之间并不关心各自的内部细节。其中，构件也称组件，是完成确定功能的粒度适中的、几乎独立的、可替代的软件系统部件。目前，主流构件规范是Microsoft的DCOM/COM+, Sun的EJB以及OMG的CORBA规范等。我们考虑到构件重用的实际效果更多体现在软件离线开发与组合（软件物理模型的部署），同时受限于其采用的通用基础中间件的规范不同，因此GI的开发采用的是类CORBA系列规范，而不是支持构件模型的3.0规范。但，我们研究会利用构件的思想去分析、定义相关类的接口。换言之，GI的开发做到“源代码”级的构件实现而不是真正意义上的二进制级的构件实现。(不知道，有多少人还记得清华的潘爱民老师，其对围绕的组件设计的总结，到位)

2、中间件

随着网络技术的飞速发展，由于网络环境下硬件和软件平台的多样性，大型应用系统通常要求在拥有多种软、硬件平台(即异构平台)的分布式环境下运行。为了更好地开发和部署能够在异构平台上运行的应用系统，需要一种标准的、独立于计算机硬件以及操作系统的开发规范和运行环境。同时，基于封装和重用等软件最新设计理念，分层屏蔽具体的硬件访问、网络协议解析和相关通用软件技术实现细节。该环境位于网络、操作系统之上，为应用设计者提供一组通用的服务和协议，并隐藏底层复杂的处理细节，保证了分布性在该环境之上的透明性。相应地，开发者可以更好地关注于业务逻辑，实现真正面向需求的应用。

通用基础中间件(Middleware)技术由此应运而生，成为支持分布式应用的有效开发、部署、运行和管理的分层支撑的规范约定。即，中间件位于操作系统之上，是一种独立的系统软件或服务程序。分布式应用软件借助这种基础软件实现在不同的技术之间能够共享资源，包括计算、存储资源和网络通信。GI早期代码的核心或基础实现部分就是利用通用基础中间件的实现，顺承其分层体系，在屏蔽分布式环境下的各种异构实体基础上，进一步封装不同学科典型计算服务，统一领域实体数据访问，从而便于油气E&P领域不同学科专业应用软件的开发与集成。

3、统一建模语言（还记得IBM的ROSE?现在已经在开源和敏捷开发冲击下，不再那么突出）

统一建模语言(Unified Modeling Language, UML)是由Rational公司的专家，Gray Booch，Ivar Jackson和Jim Rumbaugh联合开发的面向对象的建模语言。UML融合了Booch、OMT和OOSE等方法的基本概念且包容了其它学者和软件厂商的建议，被国际对象管理组织（Object Management Group, OMG）批准为标准建模语言。UML由视图、图、模型元素和通用机制四个部分组成：视图用于表示建模系统的各个方面；图由图片组成，是模型元素的符号化；模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本常用概念；通用机制用于表示其他信息，如注释、模型元素的语义等。

UML可以用于商业建模和软件开发建模的各个阶段，站在不同的视角为系统的架构建模形成系统的不同视图。其目标是以面向对象的方式来描述任何类型的系统，包括针对需求模型、结构模型、行为模型以及实现模型的可视化建模，语义定义等[34]。如，用于需求捕获与描述的用例视图；用于系统静态结构描述的类图和对象动态行为的协作图和序列图等。我们在研究中，从需求模型捕获、到体系结构设计，到领域实体的静态和动态描述均采用UML建模语言，UML不同建模表达贯穿全文，构成对PetroV多视角模型表述。

4、CORBA规范（一种典型的RPC调用规范，谷歌有自己的gRPC，GI的RPC的底层采用的是RCF开源，架构设计和代码实现，支持切换不同RPC，不如谷歌）

通用对象请求代理体系结构（CORBA），是由国际对象管理组织（OMG）提出的应用软件体系结构和对象技术规范，是针对对象请求代理系统制定的系列规范。CORBA规范的核心是提供一套标准的语言、接口和协议，以支持异构分布应用程序间的互操作性及独立于平台和编程语言的对象重用。CORBA（2.X）系列标准围绕三个关键成份构建的：对象请求代理（ORB）、接口定义语言（IDL）、标准协议（IIOP）。由于现在的软件系统规模越来越大，要求一个系统完成的功能越来越多，尤其是考虑到支持近年来软件开发技术的一个重要进展（构件化），OMG组织并制定了一个用于开发和配置分布式应用的服务器端组件模型规范（CCORBAComponent Model，CCM)，也称CORBA（3.0）规范。该规范主要包括抽象组件模型、组件容器模型和组件的配置与打包规范定义。

遵循CORBA（2.X）规范，GI为油气E&P领域的不同学科应用软件开发屏蔽了分布式开发环境的复杂性。同时，通过“软总线”（ORB）的不同消息沟通机制集成了不同学科的应用软件。GI的核心实现就是CORBA（2.X）系列规范的中间件实现。GI修改了相关并发请求策略、异步通讯策略等通用软件技术实现，并基于其提供的IDL编译器形成了领域典型服务，如空间数据访问引擎，油气检测计算服务等。

5、OpenGIS规范

为了促进地理信息的互操作性，开放地理联盟(OGC)的核心任务之一是制定满足不同协作层次的系列规范，也称OpenGIS规范。OpenGIS系列规范通过集成最新的分布式计算环境，使联盟成员之间能够共享国家和全球空间信息基础设施，建立一个无边界的、分布的、基于组件的地理数据互操作环境[41]。与传统的地理信息处理技术相比，基于该规范的软件将具有很好的可扩展性、可升级性、可移植性、开放性、互操作性和易用性。其中，简单对象管理规范（Simple Feature Specification for SQL,SFS），也称面向关系数据库的简单对象规范，是系列商业关系数据库开发具有空间对象管理功能的基础规范约定，比如Oracle Spatial等。

GI的领域实体持久化与数据管理引进了OGC的简单对象规范（SFS）。一方面为油气E&P领域的基础实体对象约定了统一的空间对象定义；另一方面突破了传统关系数据库（RelationalDatabase Management System, RDBMS）的数据类型表达的限制（因为SQL92规范没有定义空间对象类型及相关空间查询关键字）。最后，我们通过定义自主空间索引表和版本管理表为油气E&P领域实体的管理、查询提供了快速空间关系识别、空间查询与分析计算等功能，为油气E&P领域实体对象的管理与使用提供了全新的技术手段。

6、POSC （Epicentre）规范

POSC（PetrotechnicalOpen Software Corporation）组织自1990 年成立以来，致力于开发石油综合软件集成平台技术。其旨在发布面向石油工业的系列信息化标准，反映了百名甚至更多美国石油工业和计算机领域专家研究成果：涵盖国际石油勘探与开发行业计算机软件的集成和规范化，为石油勘探开采技术应用过程开发并输送一套工业标准化的、开放系统的、软件集成平台。POSC系列标准主要包括：面向互联网数据交换的系列标准，该系列标准主要是基于扩展宏语言（Extend Mark Language, XML）进行相关数据模型描述的标准，如WITSML等；‚面向E&P实际生产的系列标准，其典型标准是面向油气E&P领域的信息分类标准，是基于知识、信息和数据模型（Knowledge Information Data, KID）驱动的数据库存储方案（DataStore Solution, DSS）的主要技术基础；ƒ面向油气E&P领域的数据模型定义的系列标准，典型标准是Epicentre标准。其基于关系理论建模勘探与开发涉及的Epicentre数据模型，给出了统一数据存储与互操作等规范；

GI的整体软件设计理念遵循POSC约定的面向油气E&P领域的综合软件集成（Software Integration Solution, SIS）的理。，在兼容POSC典型协作规范和数据模型标准情况下，引进最新的信息科学技术（如面向对象技术）在数据建模、应用软件开发的最新成果，给出了基于通用中间件技术的油气E&P综合软件集成方案与实现。

1.1.2面向对象、模式、框架与组件

（1）面向对象

面向对象技术意味着软件工程的第一次飞跃。即，传统（也称结构化）软件工程向面向对象的软件工程（Object Oriented Software Engineering，OOSE）的飞跃，促进了结构化方法向面向对象(Object Oriented，OO)方法的演化，从理论上解决了分析与设计之间的偏离问题。传统结构化方法面向需求分析，采用的是功能分解或者数据流为中心的分析方法，很容易形成功能与数据分离，不能直接映射问题域，导致分析与设计之间的偏离。而面向对象分析技术，用对象和类的观点来看待问题域，建模对象。其能够直接、自然地映射问题域，支持分析模型到设计模型的平滑过渡，尤其在对需求变化的适应性及支持软件重用等方面有很好表现。面向对象技术有四个基本特征：抽象、封装、继承和多态性：抽象，严格意义上说一种归纳思维体现，也可以认为是透过现象看本质，抽取对象的共同特性，以约定的多态接口和成员变量进行体现，同时多态接口忽略实现细节等；‚封装，对象通过接口对外提供服务却隐藏其实现细节，其它对象可通过向该对象发消息来获得服务，封装使得在修改对象的实现时不致于影响其它对象对该对象的使用；ƒ继承，允许一个对象向另一个对象传递自己的能力与行为；换言之，两个实体之间的IS-A关系描述：即，其中一个实体（子类）乃是基于另一个实体（父类）而定义的；„多态性，在运行时通过匹配的接口，用一个对象去替代另一个对象的能力。

说明的是，面向对象方法到90年代以后逐步走向实用且出现了许多面向对象分析与设计(Object OrientedAnalysis & Design，OOA&D)的方法[6]。其中较著名的方法有: Coadburdon方法、Booch方法、OMT方法(Rumbaugh)、Wirtf-Brock方法等。而统一建模语言（Unified ModelingLanguage，UML）的出现，标志着面向对象方法学真正走向成熟。UML不仅统一了Booch、Rumbaugh和Jaeobson的表示方法，而且在不断发展，目前己经成为广为接受的标准建模语言。基于UML建模语言，面向对象技术关注点主要包括：如何识别合适的对象，对其进行数据和对数据操作的封装；‚如何决定对象的粒度；ƒ如何指定合适的接口；„如何描述对象的实现等；…对象之间的关系约定偏于继承而非组合与委托。面向对象技术的软件复用结果是一组相关的、可复用的类的集合，这些类提供了通用的功能，也称工具箱（或类库），强调了核心共性代码和静态行为的重用。

图（1.1）说明了一个典型专业应用软件与基于面向对象技术封装的类库之间的调用关系。专业应用软件定义了面向本领域应用的全部功能以及基于事件驱动的交互过程，而部分共性、基础性的功能实现通过显式直接调用类库的相关类和把它们加载到当前应用软件进程中来完成既定的功能实现。显然，类库的封装主要体现在抽象数据类型（ADTs）、常见字符串操作（Strings）、多线程同步机制（Locks）、常见数学计算函数实现（Maths）、常见文件访问、操作（Files）等。

   图 1.1 类库与应用软件

（2）面向模式（下面的三位老外牛人，对我帮助极大）

相对来说，设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。因为开发者相对容易封装对象，以适度的粒度进行归类，并定义类的接口和继承层次，建立对象之间的基本关系。但，当下软件的设计与开发不仅仅需要对手头问题（当前需求）有针对性解决方案之外，同时对将来的问题和需求（需求的变更）需要有足够的通用性。因此，当前信息科学的软件设计与开发继面向对象之后又进入一个新的里程碑阶段。即，设计模式概念的提出，其强调了面向不同领域时软件开发经验的共享以及通用技术的典型实现。

尤其Gang Four提出的23个经典设计模式对传统面向对象技术的继承机制有了全新的拓展（换句话说，面向对象技术不再简单意味着继承，而需要更多的强调对象之间的委托关系识别）。这23个模式归类了在对象创建、对象之间的静态关联关系、对象之间的动态行为关联关系三个方面的软件常见问题，并给出了典型的设计模式应对。显然，设计模式有适用领域和设计层次的区别，不同学者做了更进一步总结和共享：继Gang Four的设计模式提出之后，D.C.Schmidt在网络编程和分布式面向对象软件开发中总结了如ACCEPTOR、CONNECTOR、REACTOR等系列模式，并在ACE通用基础中间件开发中得到了很好的验证。M.Fowler等学者总结并定义了面向企业级应用软件开发时，在软件架构，数据库访问等方面系列典型模式，如MAPPER等。

在GI的设计与开发过程中，设计模式的应用与归纳无所不在。这也是我们第一次完整地将设计模式蕴涵的分析思维引进到油气E&P领域的领域数据模型的建模，并在整体的软件流程中做了完整的实践：从PetroV的体系结构、通用应用软件框架到领域对象之间的关联关系都在借助即有的设计模式，以减少开发成本、提供效率和软件质量。最重要的一点，拥抱需求变化的不同设计模式可以很好的设计适应性软件架构，避免软件开发过程中常见的架构湮没现象造成的高成本的软件开发过程以及低质量的软件产品。

（3）面向框架

框架是构成一类特定软件可复用设计的一组相互协作的类。框架规定了面向逻辑应用的软件体系结构，包括：类和对象的分割，组成部分（包）的主要责任，类和对象间的协作以及事件驱动的控制流程等。框架预定义了这些设计参数，以便于开发者实现该类软件时仅仅关注应用的细节而不是全部。框架记录了其应用领域的共同的设计决策，如PetroV的ST-Based KIDA模型驱动等。相对于设计模式，框架更强调面向特定领域共性逻辑的重用。举例来说，一个框架能帮助建立适合不同领域的图形编辑器，如计算机辅助设计软件（CAD）框架；或能帮助开发者建立面向特定领域应用的通用软件框架，如PetroV面向不同学科的通用应用软件框架定义。

图(1.2)说明了一个基于框架设计的典型专业应用软件实现。其中，工具箱的代码级重用是由专业应用软件的主体直接调用工具箱的代码实现，是典型的正向显式调用；而框架复用是基于抽象类或接口约定的反向控制或隐式调用，其复用的是应用的主体，通过主体代码的约定，以特定的名字和调用约定来写操作实现。如，面向不同操作系统平台界面风格实现、基于MySQL的数据存储实现、基于TCP/IP网络协议的数据传输实现等。基于框架复用技术可以方便快捷地建立特定领域软件应用，而且该领域应用软件具有相似的结构，易维护且用户看来也更一致。缺陷是，开发者相对失去表现创造性的自由，因为框架主体设计已经由接口稳定下来，开发者不能去改变接口的约定。

图 1.2 应用软件、类库及框架间关系

（4）面向构件（组件）

软件工程的第二次飞跃，即，面向对象的软件工程（OOSE）向面向构件的软件工程（COSE）的飞跃，带来了基于构件的开发方法（Component Based Development，CBD）。CBD在软件开发上体现了根本性的变革，其核心思想在于软件复用，行业分工及软件工业化: 软件复用，既在领域工程和应用工程指导下，生产和使用可重用构件；‚行业分工，既把系统开发者分为构件生产者和构件装配者；ƒ软件工业化，既通过构件的装配来建立和布置复杂的软件系统，实现可重用构件在框架上的即插即用。

构件是一些独立的可重用的代码的封装体，其实现可以基于源代码或二进制代码。另一构件的定义似乎表达得更完整一些：在定义良好的体系结构的上下文中，构件是完成确定功能的粒度适中的、几乎独立的、可替换的系统部件[15][16]。其特性主要表现为：构件遵守接口集(满足接口的约束)并提供其物理实现；‚粒度适中，是指在典型情况下，构件包括一组协作类的结构和行为；ƒ几乎独立，是指给定构件与其它构件的协作是在特定的体系结构上下文中进行的；„可替换，是指构件可被实现同一接口的任何构件所替换，以支持系统的演化和升级。

构件技术是封装的、分布的技术，构件对外只提供描述属性和方法的接口而封装其内部实现。构件的物理位置无关的特点，提高了构件的可移植性。构件具有自描述、可定制、可集成、可连接的特征。构件好比积木，形状各异的积木，可以搭成不同的模型，功能迥异的构件，可以组装成适合不同用户要求的应用解决方案。构件的优点是通过接口有效地保证了构件的可重用性，通用的构件可以一次开发，多次使用，从而避免了重复开发，做到省时省力，便于系统的管理和维护；符合标准接口的构件，可随意替换(或修改)，以支持系统的演化和升级，实现系统重构，图（1.3）中定义了GI基于构件技术封装的系列服务对象通过不同性质的连接点技术被组装成完整的计算平台原型。其中，任一服务对象的更换（由于算法的升级）显然都不会破坏整体运行的健壮性和完整性。

图 1.3 基于构件技术的PetroV智能化平台原型

最后，表（1.1）从分析范围、关键实现、适用领域、调用方式等角度对面向对象、面向框架和面向构件技术进行了比较。总的来说，同样是软件复用的技术，但复用的焦点不同：面向对象体现的是“代码”的复用，适用具体对象的封装及代码实现，受限于调用方（既应用软件）的环境（如是否是多线程调用等）；面向模式体现的是“经验”的重用，适用于特定领域共性逻辑实现的封装；而面向构件体现的是“二进制”的复用，强调了系统级别的软件组装与离线软件开发的新模式。

表 1.1 软件复用技术对比（一定要清楚，现在最新发展是面向微服务）

10.1.3 面向泛化编程和微服务

软件开发技术的重要进步，本质上是由于发掘了新的抽象性质而促成。一个所有程序开发语言都支持的决定性抽象就是结构化子函数定义，C++支持另一种抽象性质，即抽象数据类型，代码与数据的结合形成了抽象数据型别，通过系列具有明确定义的接口来操作。子函数是一种重要的抽象性质，基于函数封装就不需要依赖（甚至不必知道）其具体实现；同样道理，面向对象可以使用抽象数据型别，用来操作甚至产生新值，而不关心数据的实际表现方式，唯一重要的是接口。区别于二者，泛化编程意味着一种新的抽象性质，它是针对数据类型的一组需求条件描述，同时支持诸如编译时计算、类型推导、编译时流程分支处理等为特点的元数据编程（语言开发或描述语言）能力。面向不同数据类型的需求描述并非与C++的某个性质联系在一起，也没有任何关键字来描述，同时，泛型编程的抽象意义在于元代码推导形成的前所未有的弹性，以及不会损及效率的抽象性。它不要求通过额外的间接层来调用函数，泛化算法剥离于特定型别和特定数据结构之外，使得可以接受尽可能多的数据类型，意味一个泛化算法具有两部分：一是用来描述算法步骤的实际指令，二是正确指定其所涉及数据类型的一组需求条件。泛化组件指的就是采用泛化编程技术，充分结合设计模式和诸如C++语言特性开发的、简洁和高效率的组件。泛化组件无论是横向还是纵向，都具有极高的可重用性。从横向重用来看，少量的组件代码就可以实现组合型的、本质具有无尽数量的结构和表现；从纵向重用来看，组件的通用性可以被广泛应用于不同开发语言类型。

微服务不是什么框架，也不是什么系统，只是一种架构风格。微服务架构通过将功能分散到各个离散的服务中以实现对解决方案的解耦。与单体应用架构对比，一个单体应用处理请求的所有逻辑都运行在一个单独的进程中。这种情况下，你可以在笔记本上开发、测试、部署都很简单，还可以通过负载均衡进行横向扩展，最后交付给运维团队。单体应用非常成功，但是越来越多的人感觉不妥，尤其是在云中部署的时候，任何微小的变更都要整体重新构建和部署，扩展的时候也需要整体扩展，不能进行部分扩展。这时候微服务架构风格就出现了，它提出将应用程序构建为一套服务，每个服务都可以独立部署和扩展，运行在独立的进程中，服务之间通过RPC调用进行通信。微服务的应用致力于松耦合和高内聚：采用单独的业务逻辑封装，接受请求、处理业务逻辑、返回响应，而且喜欢简单的REST风格，而不喜欢复杂的协议，最终实现敏捷开发。与传统SOA相比，微服务更加强调敏捷和健壮，强调服务的粒度，一个服务只需完成一个单一的、独立的功能，多个微服务组合完成相对复杂的业务系统，以满足需求。而且微服务注重借助于各种中间件进行业务解耦和提高性能，以及提高服务的容错性。微服务架构有很多优点。例如，服务的拆分将复杂问题简单化；每个服务由专门的团队开发，开发者可以自由选择实现技术，提供API服务；每个微服务都可独立部署，加快了部署速度；每个服务可独立扩展以满足需求。

微服务不是免费的午餐，服务架构也有缺点。微服务概念强调了服务的大小，但是服务变小不是最终目的，微服务的目的是有效地拆分应用，实现敏捷开发和部署。微服务应用都是分布式系统，需要通过RPC进程间通信完成服务调用，这样大大增加了系统的复杂性，因此必须写代码处理由于网络或者服务不可用等导致的调用失败问题，虽然一般框架都支持相关配置，但是在这种情况下微服务显得相对复杂些；在微服务架构的应用中，建议不同的服务使用不同的数据库，这种情况下，一个交易一般会调用多个服务，同时需要修改多个数据库，由于一致性（CAP）理论和其它的一些因素，并不能实时地保证数据的一致性，因此不得不使用最终一致性的方法，从而对开发者提出了更高的要求和挑战；测试一个微服务架构的应用也是很复杂的任务，首先需要启动和它相关的所有服务。