微服务理论：面向微服务架构与传统架构、SOA对比，及云化对比( 二 ) 一、Monolith网上对Microservice进行

文章插图
图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. 服务制度不同