微服务架构是什么

  1. 云栖社区>
  2. 博客>
  3. 正文

微服务架构是什么

山顶有大风 2017-04-15 11:56:56 浏览1617
展开阅读全文

原文:http://ypj5.com/p/3332386066159616

架构师在软件行业一直有很高的位置,并且在开会中的架构师都带有主角光环。 架构师是可以说是软件的设计者,运用我们学会就会忘记的23种设计模式、企业架构模式、面向对象编程,来设计系统基础架构。基础架构开发完成后,程序员就可以愉快的在系统的基础框架里舔砖加瓦,最终完成项目的开发。
微服务和架构师有什么关系?因为微服务也是一种架构,所以还需要架构师来设计。先不说架构师了,架构师在微服务作用放到最后说。先说说传统的架构。
传统的三层架构
传统的web系统一般是采用三层架构来开发系统的,三层架构既视图层、业务层、数据层的架构。视图层负责与用户交互,业务层负责处理业务逻辑,数据层负责数据的处理。一般系统上线发布,都是打成一个包,部署在中间件中,业务代码全在一个进程中。对于需要高可用的系统,架构会设计成集群,web应用会运行在多个主机中。
这种架构的系统看起来没什么问题,不重要的系统,单例,一个进程。重要的系统,集群,多实例。其实这种架构问题很多,不然也不会有现在的微服务模式。 传统架构的缺点:
1、难以维护: 代码极度臃肿,有些小系统的代码竟然达到100m甚至1G,里面不知有多少无用的包和个版本积累的无用代码,代码难以维护。 2、稳定性差: 稳定性差主要有几个原因: 1、代码原因:代码越多,bug就回去越多。因为代码都是运作在一个进程中,某块代码出现问题,就会导致系统运行缓慢、不可用,甚至进程崩溃问题。 2、中间件原因:中间件也有bug,有时也会罢工,它一罢工,系统就整个崩溃了。 3、依赖系统问题:依赖系统出问题了,也可能会导致本系统最终不可用。 4、其他原因:数据库、操作系统、硬件存储等。 3、难以扩展: 系统不好集群,集群了,负载不一定好用。无法动态扩展。 4、发布成本高: 因为是集成到一个包,所以修改的代码难以确定修改的范围和影响的范围,不知道影响范围,有时需要全面测试,直接导致测试周期拉长,上线后修改的代码还可能引起其他问题。
微服务是什么?
微服务,不同的人理解不同。我的理解,微服务在软件中,就是一种软件架构模式。是系统的调用架构模式,是将系统分割成单独模块,提供api工其他模块调用,可以单独部署,单独运行在服务器之中,可以说是天生的分布式系统。
微服务解决了什么问题?
1、稳定性提升:业务按模块划分,实现了进程级别、容器级别甚至操作系统级别的隔离,互不影响。运维的核心可以从解决问题转变成主动发现问题。 2、易部署:轻量级部署,影响范围可控,系统其他模块可以正常运行。 3、易交付:因为代码较少,测试较快,说要交付周期缩短了。 4、易扩展:模块代码是轻量级的,容易快速扩展。
微服务的通信是什么? 模块相互调用就需要通信,通信首先方式是rpc,以保证其性能。对接过soa系统开发人员可能比较清楚,soa用的是http协议,调用都是访问网页一样,性能较差。可以说,没有好的rpc框架,就不会有好的微服务。现在的rpc框架有Netty,dubbo,HSF,ZooKeeper。
微服务是不是糖衣炮弹,有没有陷阱? 微服务是不是糖衣炮弹,搞不好真是,为了避免炸伤自己,有些陷阱还是要注意。
1、减少多样性:因为为微服务是可以使用不用语言实现的,会增加项目的后期维护成本,最好一个项目都开发语言不要超过两种,不要java、c、c++、c#、python、delphi、node.js、go等各类语言都来了。 2、要有熔断机制:微服务因为是模块化,模块之间调用会非常频繁,如果没有熔断机制,一旦一个模块出现问题,可能会导致调用链出现问题,最后导致系统完全崩溃。
3、一定要有服务监控:一定要有服务监控,最好可以监控每个服务的调用链,及时发现问题。
要不要用微服务? 微服务是一种软件组织、协作的模式。对于一般的管理系统,不建议采用微服务模式,但是可以将容易出问题或者需要与其他系统交互的模块,进行拆分,做成微服务,这样可以进一步提升系统的稳定性。对于大型系统是否采用,这个就需要软件的架构师去评估了。

网友评论

登录后评论
0/500
评论
山顶有大风
+ 关注