单体(或近似单体)运用时期 => SOA系统大集成时期 => 微做事时期，这个过渡也就十几年近二十年的韶光。
说实话，不能说哪个架构更好。这不能纯挚归结为技能问题，须要结合公司的业务规模、团队情形、IT硬件和软件状况。只能说，当前哪种架构更适宜公司，最得当的便是好的，无需考虑太长远。事实上，大部分公司都没有走到当初考虑的那么远。
单体运用时期实际上也有运用间通信的需求，这也便是最开始的分布式。
最开始的运用间通信，盛行的是工具间互操作的代理协议(IIOP)，也便是说，你要调用我的东西，那么我把我的接口按协议规范天生一些代理类，你的程序员把这些代理类引入程序中，在程序中再像调用本地方法一样调用接口就行了。运用间耦合性很紧密。代表当然便是CORBA。
后来，Java风生水起，J2EE更是迅猛，势不可挡。大型运用开拓，很少有不考虑J2EE的。不过多久，Java桌面运用awt/swing等技能逐渐淡出舞台，就连基于它们的WebStart也逐步消逝了。只因J2EE方便的分布式通讯支持，J2EE生态的迅速完善。
当时，Java与Java进程间的通讯，最方便的自然是RMI，当时条件下，确实算方便。而J2EE更是全面支持了IIOP，形成了以RMI-IIOP为根本的分布式通讯规范。它便是EJB。
EJB的涌现，让Java运用与系统中其它措辞实现的运用之间可以通过RMI-IIOP进行良好的互通信。这已经是一个飞跃了。
这个时期，可以说是IT飞速发展的黄金时期。不只是海内，全体IT界都是如此。
想当初，一个别系便是一个单体运用或少数几个运用组成的近似单体运用的时期，当懂得MVC模式，能闇练利用Struts，能用JSP写出不怎么俊秀的页面，外加如果会用点Hibernate操作数据库，在人才市场找事情是非常吃喷鼻香的。如果还懂得些EJB知识 ，那更是抢手，很多口试官司们也以自己轻微理解些EJB知识为荣。如果能对Struts的视图层作些修正，比如将jsp更换成模板措辞velocity/taperstry，一样平常会被人认为是牛人。不害臊的说，当初参与开拓了一套框架(库的形式)，基于struts1.0，并主导了把struts的视图层默认的JSP更换为基于XML的xforms技能，在当初实现了同一套运用代码能在不同的设备上的浏览器中是动态适配(当初紧张是PC和PDA，实在也便是给每种设备类型做一个xslt文件用来将DOM内容自动转换身分歧的html而已)，被同事们认为是大牛，真是愧不敢当！
后来的发展，相信很多人都有经历了，SOA。
基本从08年开始，谈论SOA的话题逐步的多了起来，干系的专题研讨会也开始多了起来。当时还身在华为存储及网络安全产品线，部门也有人率先投入到对SOA的中，率先学习研究，起到专家引领之浸染。那时候，我还是专心做我的开拓事情 - J2EE后台开拓，实际上便是写几个Web运用，写几个EJB，当时用的是JBOSS，对SOA没有多少投入，便是看看书，百度一下，知识不成熟。
接下来的五六年，才是SOA的盛世，也是中间件技能的最壮盛期间。
在这期间，如果对SOA有比较好的理解，还能够熟习一两个商用中间件如WebLogic, WebSphere，Service Bus，那跳槽到干系的中间件公司，是可以得到好报酬的，也可以说得上是知识变现。这段韶光，基于SOA的业务流程引擎BPM也得到了长足的推进，说来如今也还是用场广泛。
实际上，SOA发展的这段韶光，运用间HTTP通信已经开始作为一种紧张的通讯办法。SOAP， WSDL WebService，基本是开拓职员须要节制的基本知识，尤其是Java开拓者 和 作SOA系统集成的开拓员、顾问等。
XML很标准化，生态很成熟，以是操作很方便，但额外开销很大，效率也比较低，虽然有各种解析工具，如JDOM, JDK DOM API, SAX API，XMLBean等等来应对大大小小的DOM内容，但难免有时实际内容大小还没有标签大，至少就通讯上面便是个摧残浪费蹂躏。技能的发展每每是这样，痛点的地方很快就会涌现更好的东西来办理它。
REST + JSON。
接下来的事情，大家都知道了，Docker的涌现，让DevOps真正有了事实上的根本，瞬间火热。K8S的开源，丰富的特性，开放的架构，灵巧的可扩展性，成了Ops的标准工具。可以这样说，犹如Spring险些统一了Java开拓框架一样，K8S险些统一了运维工具集。这个在云打算和云原生运用开拓确当下，尤其如此。
说这些太啰嗦了，由于都是如今日常事情中常见常用的东西。
