一、Monolith
网上对Microservice进行介绍的文章常常以Monolith作为开头，我也不会例外。原因是，知道了Monolith的不便之后才能更容易地理解Microservice架构模式所具有的各种优点。
首先请回想一下我们所开发的服务是什么样子的。通常情况下，这个服务所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目将被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。接下来，我们需要将该WAR包上传到Web容器中，解压该WAR包，并重新启动服务器。在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了：
这种将所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后，软件开发人员可以趁着编译器编译代码的时候冲杯咖啡，并在回到座位后花费一分钟部署刚刚编译出来的WAR包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。
如果应用的部署非常麻烦，那么为了对自己的更改进行测试，软件开发人员还需要在部署前进行大量的环境设置，进而使得软件开发人员的工作变得繁杂而无趣：
从上面的示意图中可以看到，在应用变大之后，软件开发人员花在编译及部署的时间明显增多，甚至超过了他对代码进行更改并测试的时间，效率已经变得十分低下。
在变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用C++和Java几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
除此之外，由于按照Monolith组织的代码将只产生一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复地部署这些WAR包来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组成：
但是这种扩展方式极大地浪费了资源。就以上图所展示的情况为例：在一个服务中，某个组成的负载已经达到了90%，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。由于Monolith服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例虽然可以将需要扩容的组成的负载降低到了45%，但是也使得其它各组成的利用率更为低下。
可以说，所有的不便都是由于Monolith服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是Microservice架构模式。
传统应用架构
传统的企业级应用是单体应用（monolith application），一般是分层结构，如表现层/应用层/领域层/数据层，这主要是水平切分的思想。
随着互联网应用的发展，特别是大型电商系统，业务非常复杂。这种巨型系统，首先要关注的是如何根据业务划分子系统，然后是子系统间如何协作，最后才是子系统内部实现。SOA设计可以很有效支持前面两步，在SOA体系里，每个子系统是独立的服务，服务接口体现子系统协作关系，至于子系统内部，直接作为黑盒子处理。
所以对于复杂系统，首先采用SOA垂直切分子系统，然后使用分层设计水平切分单个子系统，服务化把传统的分层设计往前更推进一步。
当然SOA本身也在不断发展，最初跨企业的Web service交互可认为1.0时代；支持企业内部系统间轻量级访问，支持服务治理，可认为2.0时代；服务进一步分层和微服务化可认为3.0时代。
Web应用程序发展的早期，大部分Web工程是将所有的功能模块（service side）打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。其他语言（Ruby，Python或者C++）写的程序也有类似的情况[5]。
图1. 传统服务（Monolith）架构
但是，上述的好处是有条件的：应用不那么复杂。对于大规模的复杂应用，巨石型应用会显得特别笨重：要修改一个地方就要将整个应用全部部署（PS：在不同的场景下优势也变成了劣势）；编译时间过长；回归测试周期过长；开发效率降低等。另外，巨石应用不利于更新技术框架，除非你愿意将系统全部重写（代价太高你愿意老板也不愿意）[5]。
2. 微服务架构
微服务是为适应当前互联网快速发展，互联网应用快速迭代、快速部署而产生的技术架构，微服务强调的是在共享硬件资源的基础上隔离，缺乏软件共享；相当于敏捷的建立了很多小烟囱系统，虽然降低耦合，但是未有效的解决信息孤岛。
微服务所设计的每个微服务都要非常容易被抛弃、被替换。拥抱不断变化的业务，快读迭代开发。微服务设计目标是降低系统复杂度，提高开发生产力，是适合敏捷方法快速建立持续改进的系统，例如互联网应用，而信息共享是需要通过另个维度来解决。
图2. 微服务（Microservice）架构
微服务架构云化方案一般融合Docker和DevOps技术，解决租户隔离和统一开发平台的需求，依赖IaaS，以此形成云化。
例如以建设企业办公楼为例，微服务借助DevOps工具，使用服务化的建筑预制件快速搭建需要的办公楼（室），其中内含水电等都是独立的。
3. 轻量级SOA架构
在传统企业级SOA实施中，服务架构设计也采用轻量级模式，把业务、平台组件拆分为细粒度服务，按服务内容分别创建并管理服务容器，架构模式与微服务类似，主要差异是需要基于SOA GIRD（有的厂商为ESB），提供BPM、MDM等企业级组件。
在上述轻量级SOA架构中，每个服务容器可以单独完善、优化，可以达到系统不停机，特别是在信息共享和系统集成方面，是优于微服务架构。
轻量级SOA架构云化方案是使用PaaS方案，企业私有PaaS，是统一运营平台、统一开发平台，是为传统大型企业解决信息孤岛问题，以及企业信息化优化、统一管理而形成的解决方案。
私有PaaS强调SOA，SOA很多的应用场景都是在对已有应用的打通，比如你买了SAP的软件，又买了另一家的软件，还有以前投资定制开发的软件。这些软件都很贵，要像祖宗一样供起来的，轻易不敢改动，而且有大量历史数据，改动成本很高。所以要尽量保留，要通过SOA的方式对接在一起。
再以建设企业办公楼为例，通过PaaS平台统一构建企业办公楼，每个单位或部门按需租用办公室，内部共享使用水电等资源，每个水、电、门禁资源是统一管理的，也可以个性化，并按使用情况计量。
4.微服务架构与 SOA 服务化的对比
我们看到微服务架构的一些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA 服务 化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华井落地的一种实现方式。 SOA 服务化的理念在微服务架构中仍然有效，微服务在 S OA 服务化的基础上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。微服务架构与 S OA 服务化虽然一脉相承，却略有不同，如下所述。
1. 目的不同
SOA 服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和 ESB 。
微服务使用 一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏 捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业 的事，缩小变更和法代影响的范围，并达到单一微服务更容易水平扩展的目的。
2 . 部署万式不同
· 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术 来实现自动化的容器管理 ， 每个微服务运行在单一 的进程内，微服务中的部署互相独 立、 互不影响。
• SOA 服务化通常将多个业务服务通过组件化模块方式打包在一个 War 包里，然后统一部署在一个应用服务器上。
3. 服务植度不同
· 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分到职责单一，甚至小到不能再进行拆分。
• SOA 对粒度没有要求 ，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部 实现可以更粗粒度。
由此可见，微服务和传统服务的架构特点差别还是很大的，而微服务的特点也更加的突出，再我们选择系统架构的时候，还是要抛弃传统的架构模式，选择向微服务靠拢，从而实现更加灵活多变的系统。
5.微服务与SOA二者云化比较
- PaaS平台是不依赖IaaS，可以独立存在的，微服务云一般依赖IaaS来实现云；
- PaaS实现软件层面的共享，能全面支持Gartner多租户模型，而微服务云平台仅是通过IaaS实现硬件资源的共享，以及容器的隔离；
- PaaS平台符合Gartner多租户模型4到7高级模型，而微服务云平台最多符合1到3级资源层级的模型；
- PaaS平台是统一可运营的平台，适用于大型企业，微服务云平台是个敏捷平台，更适合互联网多变的应用；
- PaaS平台强调可重用、复用性强，继承信息化资产，微服务云平台的微服务强调的是重写，快速应变；
- PaaS平台采用成熟中间件产品，例如Opentext的产品，平台稳定，高可用；微服务云平台微服务因为采用分布式系统而产生的复杂性和稳定性问题，而且测试、维护也复杂；
- 微服务强调替换比利旧重要；
- 基于PaaS平台开发的应用，天生就是SaaS。
5. 总结
综上所述，微服务云平台与SOA云平台，都能实现云，为最终用户提供SaaS，差别是适用场景上，在传统企业级应用中，基于SOA的PaaS更适合解决信息孤岛问题、消除部门壁垒、利旧信息资产；从技术层面来说，差别也不是很大，都是在服务化的体系和云的体系之下。
转自：https://blog.csdn.net/xiaoyw71/article/details/75008335