微服务拆分需要考虑的必要因素与坚持原则

原创 2017年11月10日 08:34:47

前言:创业公司往往因为有限的时间和投入,把系统所有的功能都聚集在一起。随着业务的不断发展,技术人员开始不断地对架构进行解耦和拆分。微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,或者在做微服务的路上,拆分服务是个很热的话题。那么我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?这里我想谈谈系统拆分需要考虑的因素和坚持的原则。

业务因素

所有技术方面的考虑,包括架构设计和解耦拆分都要考虑业务的需要。在服务拆分时,先从业务角度确定拆分的方案。拆分的边界要充分考虑业务的独立性和专业性,比如搜索类服务、支付类服务、购物车类服务,按服务的业务功能合理地划出拆分边界。避免按团队来定义服务边界,这样做会出现土匪抢地盘的局面,严重破坏团队之间的信任,削弱创新的潜在机会。

投入产出

衡量拆分收益的标准是拆分后的维护成本要低过拆分前的维护成本,也就是说不能因为拆分而带来更大的维护工作。

拆分前的维护成本 - 拆分后的维护成本 ≧ 0

服务的维护成本包括维护该服务所需要耗费的人力、物力和时间。如果一个系统拆分成两个或两个以上,导致所有的资源都加倍,那将会很失败。最好的结果是原来维护服务的同一套人马分成两个部分,因为拆分后服务的复杂性降低,所需要的维护资源显著减少,或者对人员能力的要求大大降低。

组织结构

拆分不仅仅是架构上的调整,也意味着要在组织结构上做出相应的适应性调整,确保拆分后的服务由相对独立的团队负责维护,尽量不要出现在不同服务之间的交叉调用。在这里要坚持的原则是明确每个服务的分工,充分授权而且自给自足的相对独立。切不可出现一个服务由几个不同的团队共同负责的情况,这会造成无人负责或多方争抢,也不利于团队积累相关服务的经验。

这里写图片描述

系统扩展

拆分的一个重要理由也是最有价值的结果是提高了系统的扩展性。用户对不同的服务有不同的并发和性能方面的要求,因此服务具有不同的扩展性。把具有不同扩展性要求的服务拆分出来分别进行部署,可以降低成本,提高效率。比如电商平台的搜索服务有很多请求,需要特别好的扩展性,应该把搜索服务分离出来,单独考虑其扩展性的需求。这样可以确保不会因为搜索服务突然繁忙而影响其他的服务。也可以根据搜索服务的特点,设计出适合扩展的部署方案。
这里写图片描述

软件发布

系统中经常变动的部分大约只占20%,剩下的80%基本不变或极少变化,因此软件的发布周期完全不同。我们可以把不变的80%分离出来,单独部署,单独管理。这不仅有利于降低系统的复杂性,精简团队的规模;也有利于在系统发生故障的时候快速定位。如果不做这种拆分,系统在扩展的过程中会浪费很多资源。
这里写图片描述

信息安全

不同的服务可能对信息安全有不同的要求,因此把需要高度安全的服务拆分出来,进行特别的部署,比如放在防火墙的后面,可以更有针对性地满足信息安全的要求,也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求,降低成本,提高效率。这就像对家里不同房间的安全做不同的安排,确保需要加锁的加锁,减少了对锁的需求量,也减少了开门的麻烦。

总结

所以我们在考虑服务拆分时,要坚持:面向业务、大道至简、分而治之的三个原则,充分考虑业务需求、投入产出、组织结构、系统扩展、软件发布和信息安全等方面。不能只从技术角度出发,把服务切成很多细微的小块,这样做很有可能会出现劳民伤财、欲速而不达的结果。

作者简介:陈斌,陈斌现任易宝首席技术官(CTO),一直专注于互联网技术领域的探索和创新,拥有丰富的海外经历、多年的架构经验,深谙移动互联网对传统行业的影响。作为业界最前沿技术的实践者和布道者,致力于推动移动互联网技术引领行业变革,出版过多本书籍,荣登京东新书销售榜第一名,并获中央电视台隆重推介。(责编/魏伟)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/FL63Zv9Zou86950w/article/details/78495918

CE函数库Operations—2几何体拆分视频课程

-
  • 1970年01月01日 08:00

微服务化系统拆分设计的原则

最近刚好有机会处理把巨型运用拆分成微服务,无意中看到这个,觉得很赞的! x轴:水平复制,即在负载均衡服务器后增加多个web服务器; z轴扩展:是对数据库的扩展,即sharding(分库关注...
  • itsoftchenfei
  • itsoftchenfei
  • 2016-12-08 15:07:20
  • 3210

聊微服务:先做好你的服务拆分

随着自动化运维等相关技术的发展,微服务变得更容易管理,这给了微服务架构良好的发展机会;同时,Docker 等容器技术的发展,使微服务架构的落地变得更加方便,这更是为其成为主流技术铺好了道路。目前各家对...
  • sully2008
  • sully2008
  • 2017-09-12 11:10:55
  • 1893

简单说两句微服务拆分

上周六参加了魔窗组织的一个线上跨境茶话会Live的交流活动,主题是《微服务的挑战》,虽然另外两位嘉宾和我的背景各不相同,所在的企业的业务也完全不一样,但是聊到后面,大家的观点还是基本一致的。针对里面的...
  • xiedongsheng
  • xiedongsheng
  • 2017-09-28 00:00:00
  • 566

微服务的4个设计原则

微服务架构演进过程最早是应用是单块架构,后来为了具备一定的扩展和可靠性,就有了垂直架构,也就是加了个负载均衡,接下来是前几年比较火的SOA,主要讲了应用系统之间如何集成和互通,而到现在的微服务架构则是...
  • sean_cd
  • sean_cd
  • 2017-09-26 11:30:42
  • 1916

微服务的4个设计原则和19个解决方案

一篇文章完全搞懂微服务架构,以及微服务架构的好处和缺点,以及如何该进...
  • tiandiwuya
  • tiandiwuya
  • 2017-11-15 17:48:03
  • 2283

整合微服务的简单定义

将您的整体拆分为分布式架构当然是一项复杂的任务。但是,当您转移到这种新的架构范例时,对于微型服务在基本层面的稳定视角可以在形成您的迁移和开发策略方面走很长的路。 我们要求三位软件专家...
  • ChenVast
  • ChenVast
  • 2017-09-30 10:28:27
  • 877

微服务架构实践感悟

从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念。 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netfl...
  • mindfloating
  • mindfloating
  • 2015-05-15 09:42:31
  • 23508

【Dubbo】微服务架构(二): 如何把应用分解成多个服务

工作中使用了微服务,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,同时我也会在github上写一个microservices的应用框架(地址会在后续文章给出)。 上一篇文章详细说明了单一应...
  • zsq520520
  • zsq520520
  • 2017-04-02 21:42:39
  • 1488

服务化架构需要考虑的问题

一:服务化: 这里说到的“服务”,本质上来说,就是指“RPC”。单纯的RPC功能实现,其实很简单,无非就是client发起调用,中间某个组件(甚至就是client本身)拦截调用信息,序列化后将信息传...
  • u013628152
  • u013628152
  • 2016-04-27 16:30:14
  • 5961
收藏助手
不良信息举报
您举报文章:微服务拆分需要考虑的必要因素与坚持原则
举报原因:
原因补充:

(最多只允许输入30个字)