您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iProcess 课程 角色 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
途牛微服务架构快速响应市场变化实录
 
679 次浏览     评价:  
 2018-11-16
 
编辑推荐:
本文来自于网络,本文以旅游平台的系统建设为例,介绍当系统要支持一个新的业务时,如何能够快、准、好的实现,以及微服务架构的整体过程与思路。

1背景

互联网市场是一个“快鱼吃慢鱼”的市场,想要击败别人在市场占有一定份额,就要及时提升自己技术。快速响应瞬息万变的市场正是技术价值体现之一。

例如,在大的商业环境里有许多不同的业务,每个业务的技术诉求也是不同的,可能是快速上线或者高并发或者按时交付等等诉求。

技术方案是为了满足这些对技术的诉求,这也是技术的价值体现。

总结而言,技术本质上是为业务服务,无论是架构师还是底层开发,都应重视业务与技术的结合。

这里的“快”指的是一如既往的持续性的“快”,而不是断断续续的。而且随着公司规模变大,业务增多,出于成本的考虑,我们会更希望从技术上提升系统和开发人员的效率。

下面是一个在公司里经常会发生的情况。

业务人员提出一个希望能尽快上线的需求,但技术人员需要比较长的时间进行开发。这时候,产品和开发沟通后,可能会提出做一个简单的方案临时使用,后期再进行优化。

但随着时间的推移和其他客观原因,临时方案最后就变成了最终方案。在这样的场景下,极有可能会为未来埋下隐患。

在这个事例里解释了三个问题:

为什么有些系统会越来越乱。

这样的做法下并不是真正的快,只是为了快速满足业务的需求,搭建了一个存在问题的系统。

不要相信产品说的临时方案,临时最后都会变成最终方案。

2问题分析

使用微服务之前存在的问题

1.业务妥协欠下的业务债。也就是所谓的“临时方案”。

2.系统无秩序的增长。这主要体现在系统越来越大,代码愈加冗余,模块间耦合度高。上线质量差,为了解决一个BUG结果引入更多的BUG是我们当时经常遇到的情况。

3.研发人员的流动。核心研发人员离开之后,新的研发人员对之前的文档和系统都不够了解,导致让“接码侠”来维护系统,系统越来越差。

接码侠

在中大型团队中,存在一些很大很乱的系统,很少有人敢去维护,但系统对业务又十分重要。此时公司可能会招一些人维护系统,新招的人被称作“接码侠”

问题的特征

短期看来促进业务发展,长期看来阻碍业务发展。在最开始为了支持业务,系统越做越大,但发现把系统作大后对业务的支持越来越差。

具有一定普遍性。

解决问题变得心有余而力不足。一开始发现问题的时候,认为问题可以忍耐。直到无法忍耐的时候,发现解决变得十分复杂。

3微服务

微服务架构

微服务没有一个固定的标准,更多的是经验的总结。因为它不是被发明出来的,而是从现实世界中总结出来的一种趋势和模式。

下面的内容,将会介绍途牛团队的经验,告诉各位在什么时候如何去做。

微服务的特征

面向服务:把一个系统按照提供服务类型的不同,拆分成不同的服务。

单一职责:每个服务只做自己的事情。

微:每个服务下的团队小。

自治:每个微服务有自己的独立通道,不会相互打扰。

4微服务的实践

微服务拆分

在拆分之前,要问自己三个问题:

1.是否下定决心。因为微服务需要投入大量的资源,还会有失败的可能。

2.是否对自己的业务系统有充分的了解。如果对自己的系统没有充分的了解,不建议做微服务,否则会有极高的风险。

3.是否具备实施微服务的条件。技术上的自动化水平;团队的组织架构的管理;公司或者整个行业是否支持微服务。

下面我们将以旅游系统为例,讲解微服务的拆分。

团队将系统拆为三个层面:应用层、服务层和支持层。

应用层:对业务模型进行分类,分为不同的主体。

服务层:把业务的功能按照服务的内容进行分类,并把服务从上自下的逐步细化。

支持层:是技术支持的主线,比如有服务框架、容器、监控等。

问题

基础公共服务抽象。例如发票服务是通用的服务,不需要每个业务都实现一遍,可以将其提取成一个公共的服务。

服务拆分的边界。对于有些服务按照不同的划分规则会被拆分到不同的服务内,所以在最开始时团队要约定好拆分的边界。

拆分的粒度。微服务的拆分是一个循序渐进的过程,从大到小从粗到细,没有办法一开始就拆分成最细的粒度。

服务的交互

原则:交互一定要提前约定好。

途牛团队是按照下述五个重要原则约定的。

统一规范错误码。

调用方和服务方容错处理。

接口文档。通过工具自动生成文档,清晰明了。

接口技术的无关性。

接口的兼容性。对外兼容,接口内部不被外界感知。

交互没做好,可能出现的后果

场景一:由于双方统一规范没有执行,导致双方沟通出现问题。

场景二:参数过滤。

场景三:服务方与消费方的接口兼容问题。

服务技术选择型

容器

容器技术是微服务技术最重要的一环。微服务的概念在很早就出现了,但是直到Docker的出现解决了部署复杂,运维成本高的问题,微服务技术才更多的进入大众的视线。

如上图。在以前,部署一个服务需要一天甚至更久,部署好后需要要解决一致性问题,搭建三个服务甚至需要一周时间。

在Docker内,把服务A搭建好后,为服务A打造一个镜像复制服务B,C。在一天时间内即可部署三个服务。同时,由于三个服务是统一的镜像,天然的解决了环境一致性问题。

服务框架

服务框架的选择与选择电脑组装商户十分相似,要求有一定的口碑和靠谱的硬件提供商;可以提供一站式服务,满足多种需求;安装拆卸方便,升级替换简单快捷。

以Spring Cloud为例,它具有完整的体系,能满足微服务的所有需求,且组件服务标准。

在这个框架下,可以做到组装方便,快捷管理微服务。

注册中心特点

1.将所有的服务统一管理,把所有服务编成一个有机整体。通过组织对外提供服务。例如滴滴平台出现后,个体司机在滴滴注册,由滴滴平台进行对外业务。

2.调用不再建立传统的IP+端口的形式,而是通过服务名进行调用。

3.便于外界发现和使用,否则十分容易被人遗忘或忽略。

服务重构

重构的目的是调整程序的调用,提高软件的扩展性和维护性。

重构时要考虑三件事情。

前后端分离。

不影响业务。在业务上有两个原则代价最小原则,影响最小原则。

数据。之前数据的查询是在SQL内,在把产品和订单独立到服务之后,每个服务都会有自己独立的数据库。在数据迁移时,团队将SQL查询改为接口调用。但是在订单库和总库之间会存在一些问题。后来,我们选择了双向同步的方式,保证总库数据与独立库数据一致。

服务管理

重构后上线业务会增多,但也带来了其他的问题。主要原因如下:

没有统一的规范管理

服务运行情况未知

调用关系复杂

服务不稳定

安全性

解决方法

上下线流程。只有经过架构师审批的服务才可上线。下线时会先把服务状态改为待下线状态,直到服务没有占用才真正的下线。

监控体系

系统图的绘制

促销时预估新增资源,提前做好准备

敏捷与精益

由于微服务与精益敏捷契合度十分高,团队采用了敏捷和精益的方式。

PDCA原则:

P-计划 D-执行 C-执行后的效果预期 A-循环不足之处后再从P开始优化。

这是一个通过循环往复的过程以得到持续不断的必胜。

SDCA:是一个标准化循环,只有持续转动循环,系统才能将之前获得的提升保持下去。

这两个循环相辅相成,一个不停地改善,一个把不停地改善成果坚持下来。

持续交付

可以自动的构建,部署,发布。将敏捷跟精益的实践做的更标准化,自动化。

流水线操作。(将构建,部署,发布按照一定的编排进行设计)

持续交付的意义

能持续为用户提供价值,持续收到用户反馈,持续制定更好的生产策略。

“快”的升级:DevOps理念

5总结

根据当下做出取舍

开始阶段-传统应用架构和微服务架构的取舍

发展阶段-传统应用架构和微服务架构的取舍

微服务的好处与不足

好处:

易扩展

技术栈不受限

弹性:一个服务挂掉,不会影响整个系统

不足:

破坏DRY原则,代码会重复

返工:建模一旦出现问题就会返工

影响组织架构

分布式复杂

网络环境制约:一但网络挂掉,系统就会瘫痪

事务一致性

协作成本:沟通成本高

需要投入

Q&A

Q:请问当前的架构下,实现服务的无状态化方案是什么?

A: 我们现在开发了一个TSP框架,这个框架可以满足所有服务无状态化去实现的方案。框架本身,是通过框架协议让接口被调用。

Q:如何处理前端页面权限管控问题,避免无权限用户访问页面?

A:因为样品提供的平台是B2B,并不是所有用户都可以用。只有注册用户才能访问所有的页面,否则的话只能访问一个平台的说明页面。所以我们在最前端做了一个SQL:访问的时候除了说明页面外,访问其他所有的页面必须处于登录的状态。并且我们有一个模块,专门处理平行权限的问题,保证了分销商只能看到自己的数据。

   
679 次浏览  评价: 差  订阅 捐助
相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号