官网地址

程序猿升级课

热爱开源,喜欢摸索


微服务架构(1)之前言

微服务可能是一把双刃剑,一方面他把单个问题域的复杂性降低了,服务可以独立更新发布测试;但另一方面,由于是多个技术栈支撑的整体系统,所以,在维护和交付的时候难度增加了,一旦出现问题,所有单个服务都要进行查找排除,所谓有一利必有一弊,在意识到问题的严重性后,我们要尽量把问题最小化。

一、传统的三层架构

  • 表示层

表示层,可以理解为OSI模型中的表示层,即人可以看见,可以输入或者交互的部分,比如,信息的显示,音乐视频的播放。在Javeweb中就是web接口层

  • 业务逻辑层

业务层,就是对用户输入的数据,进行处理的,比如说,当用户输入价格,然后业务层根据用户的等级,去算出优惠信息,然后确定最后支付的价格,然后返回

  • 数据访问层

在用户和应用的交互过程中,必然会产生数据,而存入数据库,这一层只对数据库进行操作,拒绝耦合

三层架构的优势

  • 1.一般公司对应用开发人员工作分配,会根据功能划分,或者是层划分,这样的好处,就是职责清晰,公司可以根据能力去选择人员开发,这样不仅有利于项目,也聚焦于个人专业技能的发展和培养

  • 2.代码职责清楚,各层定义接口,并将接口和实现分离,可以很容易地用不同的实现来替换原有的层次实现,从而有效降低层与层之间的依赖,也降低后期的维护成功。

劣势

  • 1.虽然软件上采用三层架构设计,但是这只是软件上的表现,在物理上的体现,就是打包部署,不考虑负载均衡以及水平扩展,最终还是运行在同一台机器的同一个进程中,虽然这样方便了开发人员开发,运行,也很容易进行水平扩展,但是在纵向扩展上,很难扩展,因为这个始终是一个程序包。

  • 2.随着应用程序的功能越来越多,团队越来越大,人数越来越多,响应发的沟通成本和管理成本就水涨船高,尤其是在代码提交的时候

  • 3.新人培养时间周期长

  • 4.单块架构的开发模式,在分工时往往以技能为单位,比如用户体验团队,服务端团队,数据库团队,这样的划分,可能会导致任何功能上的改变,都要进行跨团队的沟通和协调

小结

互联网时代,产品创新快,成本低,需求变化快,用户群体庞大,开发周期要求短,无论是从维护成本上,或者人员培养成本,技术沟通成本及系统扩展成本都在相应增加,所以微服务架构就突然出现,接下来,一起学习,让我们对微服务架构有一个新的认识吧。

posted @ 2017-04-01 16:07  chinesszz  阅读(113)  评论(0编辑  收藏  举报
ヾ(≧O≦)〃嗷~