《中小研发团队架构实践》问与答
这里汇集书本有关的部分问题和回答,也欢迎在这里提问。
问:你好,我是书籍的读者,请教一个问题,就是我发现Demo 里无论是Business 还是DataLayer 都没有使用接口例如IOrderLogic 也未使用Autofac 来进行处理,这个是实际项目中也是如此吗?
答:我们就是这样,并且推荐这样,在真实项目(C#项目,非Java项目)中也是如此。对于业务系统加之在一个应用内部,简单实用就好。没必要搞那么多抽象和工具,现在都是微服务,重构起来也不复杂。引入每一个工具和技术都需要考虑成本收益ROI,如果没有更复杂的业务问题,就没有必要引用复杂的工具,因为工具又增加本身的复杂度。
问:DDD都这么多年了,为什么不用DDD标准五层,还要用传统三层呢?
答:一个简单微服务应用为什么要分五层,分三层不是挺简单挺实用的吗?要解决的问题有那么复杂吗?还是模板需要。
DDD是2004年Eric那本书开始兴起的,是他个人前几年的工作项目总结,在当今微服务架构模式下,工具和技术已发生很大的变化,它是否适用,我们是否继续搬抄。
DDD是软件系统分析和设计建模方法,在分析和设计阶段它很实用,但在代码实施阶段并不一定,成功案例也不多。在设计阶段,PPT架构师是画图的,自然以模型为中心,画图或者模型就是他们的交付物,但实施阶段,接口和界面才是程序员的交付物。好交付、好验收、好度量、可视化,对于整个工程而言是非常重要的。DDD强调的是设计模型,而在微服务架构模式下,业务中台接口就是模型的体现。整个系统可以分五层,但单个应用而言,三层足以。
问:公司用到Redis 集群用的哪种方案?什么考虑?
答:
分片+主备,我知道是当前的主流方案,可为什么要这样呢?
分片:Redis最好是一个应用一个实例,数据大到要分片的情况很少。如果真的需要,不同的key也可存到不同的实例中,如果一个Key大到一个实例存不下,也很容易把key再分一下。
主备:什么情况下用得到主备,一个临时数据要搞什么主备,到底有多少价值。
现在大都是瞎用,我自已是这么觉得的。说这些可能太Challenge权威了,我浅薄、挑刺啦。如果不把Redis当缓存用,难道应该把它当DB用,这很牛逼啦。
可以定个架构层面的规范:
1.Redis当缓存用,不允许超过24小时
2.一个应用一个Redis实例
3.特殊情况再写工单,包括:分片+主备、持久化。
简单、好用!
问:想请教一下博主,你们是如何处理国内航线NFD的特价政策呢?
答:任务打底啊,FD可以每月打一次,然后特别航线、航司可以根据需要打底,NFD因为解析比较复杂,可以每周打一次,它们都属于第三节的静态数据与任务打底。这个问题太偏机票领域了,我们后面讨论通用的垂直搜索比较好。
问:国外机票走缓存,很难拿到最优票。
答:最优票价是由多供应商和机票政策决定的,缓存主要是解决速度问题,对于缓存数据的新鲜度可借助更新频率、二次确认和补偿。
问:这种查询直接用ELK 加上数据库日志订阅同步ELK 就可以了吧,上面的架构能够实现,但是感觉复杂度有点高了。
答:ES确实是用来做Search的,但主要解决高并发、大数据量场景下,还有不错的性能问题,而这是传统数据库LIKE不好解决的。对于我们这种垂直搜索,更多面对的问题是业务场景复杂度,数据量也并不大,当然对于大数据且多表关联的场景也可以用做ES来解决部分问题。还是文末的那句话: “每一个具体的技术可能并不复杂,但把它们综合起来,解决具体的实际问题,为公司为行业带来价值,并不是件容易的事。”
问:如果接触不到这些包括架构方面的东西,有什么好办法深入学习一下么,总感觉自己折腾没去实践的得来终觉浅。
答:非常认同你的观点,自己折腾,确实没有工作中实践得来有价值,实际项目中才有真实的业务场景。而大部分中间件的书籍,知识点虽然比较全而,但程序员可能只用到20%。怎么才能获得这些经验呢?需要机遇+努力,如果公司内部有机会那就好好把握,如果没有也可争取。找公司领导或者自己换个环境,比方说你当前在一个几百人研发团队,你很想做却没有实践机会,你可以跳到五十人左右的团队,然后去主导框架或架构工作,这样坚持一两年,这些知识便可过关,我见过类似的成功案例。
问1:好奇问一下,光这份文档编写,花了多少时间?整个重构花了多长时间,多少人力?
问2:我也有个问题比较好奇,当时既然大部分打算重写,为什么不直接考虑转Java生态
答:两位好,编写总体架构文档花了1个多月,重构花了5个月。原有的体系是.net的,后期也有部分项目采用java,但第一语言还是以.net为主,主要原因是历史和团队结构等。
问1:没什么干货,感觉就是把框架的使用文档复制了一遍,然后总结成了一本书,没必要买。相信我,一下午就可以看完。。。。所有的框架都只是说明。
问2:这是个大话题,是真的很薄,感觉是博文小合集
问3:适合.Net的人看,Java不合适
答:
确实不厚,200多页,但都是精华,是真正经过实战总结出来的。如果把书中的每篇文章都放大写的话,每一篇都能够写上一本书,没有必要且大部分人不会看。对于大部分框架,程序员可能只需要懂20%,运维可能需要懂另外的20%,而架构师可能多一些。在多了解其工作原理情况下,再学会其常见用法,即可满足大部分场景可,而其它更高级的知识点,可以实践中根据问题去搜找答案。以下是摘抄自书中的几句话,以表明我们的想法。
“框架篇中的每章主要由四部分组成:它是什么、工作原理、使用场景和可直接调试的Demo。其中中间件及Demo是历经两家公司四年时间的考验,涉及几百个应用,100多个库1万多张表,日订单从几万张到十几万,年GMV从几十亿到几百亿。所有中间件与工具都是基于开源。早期我们也有部分自主研发如集中式日志和度量框架,后期在第二家公司时为了快速地搭建、降低成本、易于维护和扩展,全部改为开源。这样不仅利于个人的学习成长、知识重用和职业生涯,也利于团队的组建和人才的引进。
根据我们以往的经验,分享者主讲一个小时左右,业务研发就可以快速地进入项目实战。对于后面新加入的团队成员,也可通过Wiki自主快速学习。这是我们之前对自己的要求,尽量降低工具对研发人员的门槛,简单实用、降低成本。文章中部分Demo采用C#、Java及Go语言,但到了框架与架构层面,与语言本身没有太多关系。如RabbitMQ、Job、Redis和集中式日志ELK,它们服务端的部署都是一样的,只是客户端语言版本稍有不同。所有Demo在一段时间内都可直接运行,服务地址和管理后台亦可直接访问。
使用过分布式中间件的人都知道,程序员使用起来并不复杂,常用的客户端API就那么几个,比我们日常编写程序时用到的API要少得多。但是分布式中间件在中小研发团队中使用得并不多,为什么会这样呢?原因是中间件的职责相对单一,客户端的使用虽然简单,但整个环境搭起来却不容易。所以对于中间件的使用,我们重点放在解决门槛问题,把服务端环境搭好(生产环境可直接使用云或运维解决),把中间件的基本职责和功能介绍好,把客户端Demo写好,让程序员抬抬脚,在调试代码中即可轻松入门。
本书坚持代码比文章重要,简单实用比炫技重要,基于常用场景而不是特殊场景,追求一篇文章即可快速地入门。文章完全站在程序员学习和使用的角度,以及架构师价值输出的角度,尽量提供Demo和设计案例,并且全部放到GitHub上对读者开放,希望对公司产生正面、可直接使用的价值。”
以上是我们的初衷,对于问题1中提到的“一下午就可以看完",那可能是没有静下心来。据我几个做架构师和架构总监的朋友反馈,如果把文章和Demo练习完,大约需要半年左右。建议静心下来、多动手,附上代码地址:https://github.com/das2017
问1:当团队规模超过几十人以上,才需要技术总监,当团队规模超过上百人时,才有设立CTO的必要,是这样吗?
问2:技术管理这种岗位等同于工具,一旦业务进入平稳期或衰退期,成本中心的热点就会凸显,每个岗位都有Leader在那盯着,维持着正常的业务运行。这时,还有什么规划和平台要做吗?到这天,什么CTO,什么技术总监,就等着被收拾吧,都是高危职业。
问3:我是技术总监,需要写代码吗?
答:
我知道以上是网络流行说法,但我是这样想的。技术管理是能够出效益的,早一些请CTO或技术合伙人就整个工程而言,是能够产生更大效益的。如果等出了问题再去请技术总监或CTO,往往已出现比较大的问题,背负较多技术债务。
一个好技术合伙人或CTO,在团队只有5个人时,让团队发挥5个人的价值。在团队是只有10个人时,能发挥12个人的功效。在团队有80人时,如果没有CTO,就会出现混乱,只能产生50人的价值,但如技术管理得好,可以发挥100人的功效。
在《华为基本法》里有一段这样的话“人力资本増值的目标优先于財务资本増值的目标”。以上做法是滞后的人才策略,会出现职位断裂和大量工程问题,现在真正成功的互联网公司应该不是这样。当然,愿意早些找一个好的技术合伙人,需要有潜力有远见的CEO,马云早年不是也在yahoo请技术牛人。
对于技术管理是高危职业的问题,我个人甚至觉得,所有高管都是高危,高管的终极目标就是把自己做没,不需要自己整个体系也可以运作得很好。把技术管理当做可有可无的工具,而非合作伙伴,这种老板也不值得跟,企业也大都做不大。
文人自轻不可取,跟对人做对事很关键。把技术管理当工具的,又能产生几成价值,把技术管理当合作伙伴,才会产生技术创新。业务要实现十倍、百倍的增长,传统销售和管理很难做到,但借助技术往往可以。技术管理也不一定自己要写代码,一个IT项目可以做的工作很多,有十几种包括架构设计、数据表设计、代码、测试,可行性分析等,而代码只是其中一种。有一个好的技术合伙人伴随其长大,如同孩子成长不断篇,减少空降和技术风险,实现技术创新和长远战略式发展。
问1:为什么叫《小团队构建大网站》,只适合于做网站吗?
答:
本书所介绍的技术都是基于开源或公用云,而不是像那样大厂自己写一套中间件,这样中小研发团队也可快速搭建,降低成本,易于维护和扩展,不仅利于个人的学习成长、知识重用和职业生涯,也利于团队的组建和人才的引进。这些技术不仅可以用来构建网站,也可以用于做App和小程序的后端,从这个角度而言,叫《小团队构大平台:中小研发团队架构实践》可能更恰当。有些遗憾,但这就是我当时的想法,《小团队构建大网站》其实也挺好 :)
posted on 2019-04-26 10:35 arch-system 阅读(1266) 评论(2) 编辑 收藏 举报