54

服务需要拆分到什么程度?

 6 years ago
source link: http://mp.weixin.qq.com/s/AddNefOedunV3yJdxaAaZA
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

服务需要拆分到什么程度?

Original 陈斌 泡面办公室 2017-11-08 10:39 Posted on

Image

要想富   先关注

当码农   多看书

Image

Image

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

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

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

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

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

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

Image

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

Image

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

Image

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

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

易宝 CTO 陈斌翻译的新书《架构真经》正在京东和亚马逊热卖!

《架构真经》:《架构即未来》姊妹篇,硅谷大咖的干货呈现,互联网架构的50条军规。唐彬、向江旭、叶亚明、段念、吴华鹏、张瑞海、韩军、程炳皓、张云泉、余晨、李大学、霍泰稳联袂力荐。点击“阅读原文”即可购买!

Image

要想富   先关注

当码农   多看书

Image


Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK