我设计出人生第一个框架。接下来要做的事有几个：
1、技术选型。别看架构简单，也绕不过技术选型这件事；这也是今天主题。
2、框架代码编写，然后是任务分解。这些有机会再聊。
日志模块”要做到什么程度、我们的“指令处理”是用继承还是组合等一系列编码中的技术相关决策。今天主要聊狭义的选型。
回顾上一篇的“框架图”。
我们面临的技术选型问题包括以下几个：
（1）整体框架要不要找开源的，或者从朋友那儿“借”个现成的。
（2）各类工具要不要找开源的。
（3）用什么语言写这个服务器端，c++？java？python？
我们依次聊聊。
第一个问题，框架。
粗糙点说框架选型三种：开源的，自己造，以及混合。三者各有利弊。开源框架实现简单，扩展和维护困难；自己造框架费时间，但好修改；混合的介于二者之间。
不可否认，先驱程序员们贡献了大量优秀框架，其中很多框架性能稳定、功能丰富、设计精美。但同时大部分拥有自己产品的公司都会维护一套自有框架。是那些著名开源框架不够好不够强大吗？显然不是。最简单的解释是需求的不同。各个公司、各个产品有各自的需求，一套“通用”解决方案不能正好“fix”这个需求。另外，公司是发展的，公司的发展和框架的发展未必是一致和同步的，所以一套通用解决方案在未来可能造成麻烦。
具体落在我当时情况，一来公司的目标是长期维护一个产品线，另一方面我第一步要做的事足够简单，上功能繁复的开源框架有害无益。所以，框架我就自己写了。
写框架时不能“自我感觉良好”，还得多思多试多积累经验多解决问题；但也没必要没有信心，作为一个初级架构师或者意欲往架构方向转的同学，我是鼓励大家去写简单框架的。
第二个问题，工具。
工具选型和框架选型类似。不过工具成熟的多，而且体量小，“标准化”程度相对高；所以有好的开源工具多半可拿来用。不过一些核心工具、复杂工具或者至关重要的工具还是要考虑到维护以及扩展问题的。另外很多工具拿来之后需要自己包一层。
具体落在我当时情况，网络框架选了“libEvent”，在那之上包了一层。
关于工具后续还有一些经验。
一是libEvent理解不够导致出现死锁。libEvent是“伪并行”的，也就是说，它处理大量网络回复时其实是个串行算法。当时写应用逻辑的同事理解不深导致了死锁。这是用别人东西常出现的弊端：理解不够透彻，导致意想不到的bug。
二是日志工具的废弃。当时有同事写了个日志工具，考虑得很周翔，代码量也大，后来这个同事离职。在一个大项目部署之后，为了解决内存泄露问题和系统稳定性问题，整个日志工具都被删除了；当时的判断是与其花时间去重审日志工具相关代码还不如没日志工具来得强。取而代之的是一个非常简单的日志类。所以在组织程序时没必要过早花太多心思在尚且用不上的地方；这也是架构师需权衡的事情。
三是对框架的破坏。有同事在网络模块（libEvent封装的一层）里写了业务逻辑代码造成了框架的破坏。我发现时让他迁出去，代码已经没那么好迁移了。很多没经过训练的同事接到任务后脑子里全想着如何实现功能，为了方便实现功能而破坏框架的事是常见的，这需要管理者培养，也需要架构师时考虑架构的扩展问题并跟进架构的使用情况。
维护一个良好框架的好处很多，限于篇幅就不赘述，但身为架构师一定要重视这一点：框架需创立，也需要维护。而维护有时候花的心血比创立更多，除了技术手段一些管理手段也是必要的。
第三个问题：语言。
关于语言的讨论实在太泛了。只说说我当时的情况：当时我本人是java出身的，对c++也熟；部门其他开发是c++出身；合作的BH大学从导师到博士硕士都习惯C++。所以语言选了c++。
半年之后客户端代码仍是c++（qt），服务器代码却转型成java，理由有2：
1、c++不好招人。这是个很现实的问题，尤其是对于不知名公司。我们公司已经不算小了，在知名度、薪资福利方面比创业公司和小公司都好不少，仍然面临了c++不好招的问题。一个强烈的对比是：c++的招聘信息帖出去一周后收到十多份简历，我有兴趣电话面试的只有一两个；java的周五贴出去，下周一收到好几百份，我用比较严苛的筛选一过，还有二三十份，能让我有兴趣电话面试的也有十多份。区别太大。当时我手里有的四五个c++不能不用，新招的又不足以支持客户端那边的需求，而我本人对服务器的新框架信心较足，因此大胆的弃用了原来的c++服务器，开始招聘java成员。
有意思的是，后来很多老的C++同事在我简单培训之后就直接上手java，倒是省了很多事情。
2、c++服务器的稳定性不好。这里的稳定性，不牵涉性能或者平台稳定性，只是单指发布之后程序奔溃的可能性。对于c++而言，一个指针出问题整个进程就奔溃了；对于java，指针少，而且一处内存出问题只是对于的线程奔溃，进程依然不受影响。对于当时有较多项目要部署而人力又不足够把所有项目都做到很稳定的团队，是很有必要的。
