【华为云技术分享】浅谈服务化和微服务化(下)
【摘要】 服务化来自于真实世界的映射。对于微服务,我们也要寻找真实世界的隐喻。上篇主要讲服务化,下篇我们谈谈微服务。很显然,服务化来自于真实世界的映射。对于微服务,我们也要寻找真实世界的隐喻。1.微服务,让服务化走向专业化和精细分工。2017年的某一天早上,我路过了一段因为修地铁而导致的破落的街区,又穿过稼先路与坂雪岗大道交叉路口的滚滚灰尘,转眼看到了拐角处幸存的中国银行。这一天...
【摘要】 服务化来自于真实世界的映射。对于微服务,我们也要寻找真实世界的隐喻。
上篇主要讲服务化,下篇我们谈谈微服务。很显然,服务化来自于真实世界的映射。对于微服务,我们也要寻找真实世界的隐喻。
1. 微服务,让服务化走向专业化和精细分工。
2017年的某一天早上,我路过了一段因为修地铁而导致的破落的街区,又穿过稼先路与坂雪岗大道交叉路口的滚滚灰尘,转眼看到了拐角处幸存的中国银行。这一天,我要体验中国银行的服务化。大堂入口的笑容可掬的两位美女大堂经理,证实了BOC作为四大国行之首应有的风范,也说明了其服务化能力非同小可。我要办的业务很简单,换几K泰铢,作为通向一个让我神往已久之地的盘缠。
原以为要排很长时间的队,跟着大部队一起等待叫号,然后在综合窗口完成业务,没有想到的是,BOC在外币兑换业务上实现了“微服务”,大大提升了我办事的效率。我在一楼的自助机上完成了现汇购买,然后去到二楼,穿过一处沙发所在地,感觉一点都不像在银行。8号窗口是外币兑换窗口,银行职员已经等待多时,他拿走了我的银行卡,让我输入密码,然后给了我5000泰铢。
这个外币兑换窗口从综合业务中剥离出来,成了单独的“微服务”,着实有一些好处。
其一,是这个窗口的服务更加专业化,这个窗口的职员只干这一件事,效率自然高很多,因为避免了从不同的“限界上下文”中来回切换导致的效率损失。
其二,我不会因为办理其他业务的人太多,而排队等候。
其三,这个窗口的职员不会因为处理了其他难缠的业务而导致疲倦宕机,影响这个窗口的业务开展。开卡柜台的职员去嘘嘘了,并不会导致这个窗口的服务中止。
其四,银行的职员不必精通所有业务,只要能搞定当前业务即可。
其五,我们针对这个服务的改进更加容易,我们可以优化当前的服务水平而不影响其他的服务。
很显然,真实世界中的服务的微服务化让服务化走向了专业化,走向了精细分工,带来的好处也显而易见。
2. 微服务并不是2014年才有的
谁第一个提出了微服务?看这里:http://www.sohu.com/a/136026819_609518。然而微服务的相关理念就源远流长了。
a. Amazon 2004年已经在实践 Two Pizza Team,其实已经是在做微服务了。
b. 2005~2009年期间,Fred George和所在的团队是将100万行的传统J2EE程序,通过解耦、自动化验证等实践,逐渐分解成20多个5K行代码的小服务,又分解成200多个500行代码的服务。在这个过程中,他们使用了基于Kafka的消息解耦服务间依赖。
后来的事情就比较清楚了,Martin Fowler 2014年3月正式喊出了Microservices的概念。
3. 小烟囱不是微服务
上篇已经提到,SOA的本质是前后分离,实现服务在分布式环境中的重用。如果我们简单把原来非服务化的应用分拆成多个非服务化的应用,相当于把原来的大烟囱分割成很多小烟囱,那么,连服务化都算不上,因为服务化根本的目标---在分布式环境中的重用服务,并没有得到实现。
4. 团队太大不是微服务
Sam Newman在“微服务设计”一书开篇就提到,微服务的初衷是解决“代码库过大”(或者说团队过大)的问题。为什么代码库过大是个问题?因为难以维护。通常情况下,大的代码库需要大的团队维护。漫长的软件技术发展历史早已证明,越大的团队越是效率低下,越是难以管理,这好像已经是不争的事实。这个世界上,真正能管理好大型软件开发团队的公司,基本没有。有一些公司看起来有这个能力,但往往其软件业务也在走下坡路,或者软件团队真的软了,因此,并不见得是真正的好。
我也曾经管理过比较大的开发团队,每天忙忙碌碌,过的很充实,但最后的效果一般。后来我终于明白了一件事情 ---“3-5个人做不好的事情,30-50人做的更烂。(腾讯云CEO陈磊)”。
Amazon的经验表明,6-10个人的团队是比较合适的。
5. 团队过小也不是微服务
有时候,我们过度的进行了“微服务化”,往往是违背了微服务的初衷和本质。微服务化其实是有代价的,这也是众所周知的事实。
当我们把服务拆到6-10个人的小团队可以维护的时候,就不应该继续分拆了。如果我们将服务拆的太散,最后一个人维护10来个服务,那已经背离了初衷。我们的程序猿就是这些的服务的爹妈,这些服务出现任何问题、需求、故障, 都要爹妈来负责,想想,养那么多孩子,容易么?
6. 拉通过多不是微服务
前面讲到团队太大不是微服务,其实大团队的问题并不在于大,而在于“拉通”上,“One Team,One Dream”,团队的目标是一定的,如果要在7月份交付某个火车一样的版本,各服务之间复杂的依赖关系,最终导致两个结果,要么是团队效率极低,要么是拉而不通、痛苦不堪。
微服务强调的独立,自治,就是尽量不要依赖其他服务,要内聚,这里涉及到架构上的控制,架构师如果看到某些微服务总是纠缠不清,那么应该考虑将这些微服务适当合并。
话说回来,实际情况总比理想情况复杂,总有些情况是必须依赖的,那么应该依赖那些稳定、可靠的服务。
7. 微服务的边界如何定义?
Martin Fowler 2003年的时候就讲过,分布式架构的第一原则,就是不要分布对象。任何违背这一原则的实践都会带来很大的代价。N年前,我们使用了已故公司SUN专家广为推崇的的远程EJB技术,号称可以更好的分离业务层和WEB层,最后下场是苦不堪言。
好的微服务设计就是在维持合适的团队规模的前提下,尽量少的去分布对象。Eric Evans的“Domain-Driven Design”(领域驱动设计)一书值得一读,其中提出的“Bounded Context”(限界上下文)有助于理解这一点。通常来说,一个微服务中可以包含1个或者多个 Bounded Context,但是一般不应该将一个 Bounded Context 分散到不同的微服务中。
举个例子,对于商品交易来说,销售和技术支持是两个 Bounded Context,可以实现为两个微服务。这两个微服务中,都有 Customer 和 Product,但其保有的属性不完全相同,Service Context 中一定要保留 Customer 的联系方式,而Sales Context 则未必;甚至两个 Customer 都不是同一个对象,比如买手机的 Customer 和修手机的 Customer 未必是同一个人。如果将销售和支持放在一个单体中实现,那很可能 Customer 和 Product 两个实体(表),会被 Sales和 Service 两个功能共用。而在微服务架构中,他们是两个不同的实体,各自属性不完全相同,并很有可能存储于不同的数据库中,为了保持微服务的独立性,Customer 和 Product 的数据在两个微服务中有一定程度的冗余。
那回到最初的问题,在微服务模式下,对象到底有没有分布?答案很多时候都是没有,就拿 Product 来说,Sales Context中的 Product 跟 Service Context 和 R&D Context 中的 Product 也不完全一致,是可销售的 Product ,可销售的 Product 的数据就存储于 Sales Context 所在的微服务中,虽然,其最终可能仍然来自 PBI 。同理, Service Context 微服务中,一般也存储有待服务的 Product 数据。
通过合理的 Bounded Context 来引导微服务的拆分,并适当的安排数据的分布和冗余,有助于提高微服务边界划分的合理性。
8. 微服务的代价
微服务架构小独轻松,都是优点,难道就没有缺点么?当然有:
a. 系统的可用性受到比单体应用更大的挑战。一个由10个微服务构成的系统,如果每个微服务的可用性是99%,那么总体的可用性是99%的10次方,大概是90%左右。如何解决这个问题?答案当然是技术,通过多活、限流、容错、熔断等多种技术组合,来保障系统总体的可用性不受单点故障的影响。
b. 性能的下降。单体应用中本地的调用有部分会转化成远程调用,再牛逼的远程调用也比本地调用要慢1个数量级以上。解决方案也不复杂,恰当的运用缓存技术来提升性能。
c. 更多的硬件资源消耗。就我们观察到的在多个领域的实际经验来看,应用服务器占用的资源数量增加了数倍到数十倍。一般来说,要借用容器或者Serverless技术,来改善利用率。
9. 数据库的独立是不是必要的?
很多对微服务信念坚定的人认为,“数据库不独立不是真正的微服务”。
支持独立的人认为:
a. 微服务强调独立性,如果数据都不独立,那服务不可能独立。
b. 数据独立之后,所有依赖都采用服务方式进行,有更好的内聚性。
c. A服务的数据库挂了不会影响B服务。
支持不需要独立的人认为:
a. 用户不关心你不是独立数据库。用户需要的是良好的体验。如果分割数据库导致性能下降或者可用性下降,用户可能情绪不稳定。
b. 码农基本不希望分割数据库。分割数据库之后,很多原本简单的问题,变得很复杂。
c. 架构师的担心有时候是多余的。在大型互联网应用中,因为数据量巨大,要分库分表,因此,Join一般是严格禁止的。而在企业级应用中,这种情况比较少。另外,有人担心数据库不独立,导致互相扯皮影响的事,毕竟还是比较少的。
看来各有道理,因此需要中庸之道来解决,数据既需要独立,又需要共享,那怎么办呢?一般采用集成来解决,集成可以基于服务、JMS、数据库集成,具体哪种方案,取决于对实时性的要求。
一般来说,主数据会被多个微服务共享,如上面例子中的 Product 和 Customer ,而交易数据则主要体现为各微服务独享,如订单、维修单数据。
10. 单体应用仍然是有价值的
讲了这么多微服务,这个世界上其实一直存在一个最大的反面典型,就是 Salesforce,Salesforce 其实是个巨大的单体应用。那难道 Salesforce 就不好么?其实未必。不管白猫黑猫,能解决老鼠问题的就是好猫。
不能因为走的太远,就忘了为什么要出发。从根本上来说,我们要实现的目的,无非是提供更好的用户体验和实现更大的价值重用,从这两个目的来说,微服务并非是唯一的途径,而只是一条比较流行和时尚的途径。
正如很多兄弟所说,3MS上有100篇关于微服务的文章,各有各的看法,关于微服务的争论仍然不会停止。微服务模式的价值显而易见,但微服务的关键并非技术,而是服务边界的重新定义,我们不能过度渲染微服务的技术或者框架,而忽略了对合理的服务边界的划分。另外,正如开头所讲,微服务让服务化走向专业化和精细分工,目标仍然是要实现更好的服务效率和体验。至于架构,仍然只有最合适的,没有最好的。
作者:quitgame
更多推荐
所有评论(0)