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