《中小研发团队架构实践》问与答

这里聚集书本有关的部分问题和回答，也欢迎在这里提问。

问：你好，我是书籍的读者，请教一个问题，就是我发现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和小程序的后端，从这个角度而言，叫《小团队构大平台：中小研发团队架构实践》可能更恰当。有些遗憾，但这就是我当时的想法，《小团队构建大网站》其实也挺好 :)