单体架构、SOA架构、微服务架构的浅析 - 好文

一、单体架构Monolithic：

* 单个Java WAR文件。
* 单个Rails或者NodeJS代码目录层级。

* 单体架构比较适合小项目，优点是：
* 开发简单直接，集中式管理
* 基本不会重复开发
* 功能都在本地，没有分布式的管理开销和调用开销
      它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

* 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
* 代码维护难：代码功能耦合在一起，新人不知道何从下手
* 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
* 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
* 扩展性不够：无法满足高并发情况下的业务需求
二、SOA架构：

面向服务架构 <http://lib.csdn.net/base/16>，是B/S模型、XMl/Web Service的技术延伸


DUBBO是淘宝公司的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。淘宝公司的许多应用就是采用dubbo，运行稳定成功。现在，不少企业采用dubbo开发应用系统。Dubbo是简单有效的soa架构，值得采用。

优点：

*   把模块拆分，使用接口通信，降低模块之间的耦合度
*   把项目拆分成若干个子项目，不同的团队负责不同的子项目
*   增加功能时只需要在增加一个子项目，调用其它系统的接口就可以
*   可以灵活的进行分布式部署  缺点：

* 系统之间交互需要使用远程通信，接口开发增加工作量
三、微服务架构：

具体实现手段：1、分库分表
                            2、统一的服务接口
                              3、所有的微服务都是独立的Java进程跑在独立的虚拟机上




要解决的技术难点：

1、这么多服务，怎么找?

        通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

2、服务之间如何通信？

       因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process
communication），已经有很多成熟的方案。现在基本最通用的有两种方式
3、这么多服务，服务挂了怎么办？
        相应的手段有很多：

* 重试机制
* 限流
* 熔断机制
* 负载均衡
* 降级（本地缓存）
这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
<https://github.com/Netflix/Hystrix>

* 优点
* 开发简单
* 技术栈灵活
* 服务独立无依赖
* 独立按需扩展
* 可用性高
* 缺点（挑战）
* 多服务运维难度
* 系统部署依赖
* 服务间通信成本
* 数据一致性
* 系统集成测试
* 重复工作
* 性能监控

热门工具换一换