你好,游客 登录
背景:
阅读新闻

单体架构、SOA架构、微服务架构的浅析,微服务架构搭建

[日期:2018-06-14] 来源:  作者: [字体: ]

单体架构Monolithic

 

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

  • 单体架构比较适合小项目,优点是:
  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

      它的缺点也非常明显,特别对于互联网公司来说(不一一列举了):

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

 

SOA架构:

 面向服务架构是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

 

  • 优点
    • 开发简单
    • 技术栈灵活
    • 服务独立无依赖
    • 独立按需扩展
    • 可用性高
  • 缺点(挑战)
    • 多服务运维难度
    • 系统部署依赖
    • 服务间通信成本
    • 数据一致性
    • 系统集成测试
    • 重复工作
    • 性能监控
推荐 打印 | 录入:Cstor | 阅读:
相关新闻      
本文评论   
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款