前言

过去两个月深入的参与了一个分布式系统的开发，记得之前有人说过“想成为架构师之前，都是从微观架构开始的”。尽管我从没想过将来的某一天要成为一个架构师，或者领域专家，我只是想萌萌哒的编码，写着自己喜欢的Code，和一群志同道合的朋友做出大家喜欢的商品和产品。但是工作久了慢慢的搭架子的事情还是会来到你的面前，因为时间总会把一部分人慢慢推向海边，使得他们成为最早见到阳光的人。

不扯淡了，为什么要说阳光呢，还是因为过去的两（三）个月可能过的太充实也太痛苦了，完成之后，曙光来临的时候整个人是会发光的哦。“深度”参与是因为我终于有机会在搭架子的过程中有了话语权和选择权，同时也会承担70%以上的编码工作。

之前我的自我认知是我可能在软件方面的积累还可以，比如设计模式，架构分层，程序解耦，API入手等方面，但是总觉得我在硬件网络方面积累的太少，太薄了。

项目简介

首先项目详细内容不便多说，简答的说，就是为国内某大型厂商建立一套协调其自身搭建的私有云以及其购买的公有云的一套系统。说牛X一点就是：一套混合云系统。

使用Restful

这是在构建完整个系统最大的收获，之前使用web api的经验只是为电商系统的移动终端提供数据交互的接口，但是在这次项目之后发现Rest接口的不仅作为我们系统向外部系统提供交互的方式，同时在一些开源工具其暴露出来的接口也是基于rest的，可见全世界的程序员对于json对于rest有多么的喜爱；

为什么装上软件配置完成之后使用不了

之前的开发经验由于使用的都是微软的技术包括组建，工具。但是在项目中使用一些开源工具之后，配置成功之后却总也跑不起来，同时由于开源工具已将Exception封装起来，我们很难知道具体是什么样的问题，有的时候调试好久还是跑不起来，很沮丧也很懊恼，结果最后发现是由于公司IT只是将常用的端口打开，其他的都干掉了，如果申请开放端口的话还要走流程，于是对于开发人员有时候有一台外网的开发虚拟机也是相当的有必要的。

使用RabbitMq

个人是非常的喜欢使用Mq的，之前做电商总喜欢在Application层下面放入一层Service，你可以不用但是总会强迫症似的不去不写。为什么不用Msmq呢，原因是有很多了，简单点就是rabbit要比Msmq的协议更加高级，支持的处理功能也更加丰富，最重要的原因是Rabbit在开源语言使用上是占领先地位的，而且我们的系统又要嫁接太多的开源语言系统，最后只能适配他们喽。

之前知道Mq在企业系统间数据交互使用频繁，不但能有效的划分层次，解耦依赖，同时数据交互方式上也相当的便捷。总会有消息没有被消费者使用，那我们就需要程序异步的去处理这个消息队列了。

Redis

系统中使用了三种数据存储，MySql，SqlServer，Redis，当然前两种适用于开源和C#，而Redis的使用则是为了那些总是难以找到有效关系和依赖的数据，比如之前只是知道Reids可以作为数据的存储，可以分布式，可以主从复制，但是在这次开发之后更真真的发现Reids或者Nosql对于一个数据规则难以掌握，数据量大的系统是多么的重要，因为有的时候一批的Json串过来之后，难以有效的挖出里面的关系与逻辑，索性就一次性将他们放入Redis中吧，使用时再反序列吧。同时建立读写分离的原则，我们主要将读放在了Redis里面，写到了Mysql，并通过Mysql的触发器实现服务器段数据的主从复制同步。

日志系统

之前我们的单一系统的时候，比如只是简单的3层架构的话，我们通过Debug可以从头debug到数据库，每一步都是掌握在手底下，每一步都尽收眼底。可是对于这一个层次太深，组建调用较多，同时又是多线程的系统来说，挖到雷的机会，时间，成本都是要考虑的。于是有效的使用日志组件，有效的在代码中埋雷就显的尤为迫切和必要，能够更好的帮助我们找到问题所在。

组件式开发

之前的简单分层系统我们通过Svn或其他的代码管理工具，每次提交都可以Merge看的到，但是当系统庞杂同时系统独立性很强的时候，分组建，分模块开发就显得很重要。因为不想浪费大家一起Merge的时间，我们习惯性每个人有自己的Branch每周2的时候提交代码，大家一起参与，这样减少了好多因为代码管理浪费的时间。

测试用例

之前小的系统使用测试用例基本就是装B用的，本来小小的系统整套流程脑子一想就可以知道怎么做啦，为什么还要浪费时间。可是在这次开发中充分理解了测试用例的重要性。比如我需要你给我提供多台服务器的监控数据包括CPU信息，IO信息，NEt信息等等，但是你还没有想到怎么样去抓取虚拟信息，不能因为你的问题去影响其他人的进度的，最好的方式从使用者角度获知他希望使用什么样的数据，为其建立API，同时为API建立测试用例并保证测试稳定。而后期我有了监控虚机的方式之后我在建立对应的适配方法适配到对应的API上。

所以首先肯定要保证API的稳定，因为他之上的东西已经稳定了吗，你只好辛苦啦，有效的测试用例可以帮助我们更好的剥离项目逻辑与协调组件系统。

编码原则

这个主要是每周有时间大家一起参与Code Review，由于开发人员的能力不同资历不同，所以总会在代码的编写上和建立出现太多的不统一。比如命名啦，变量声明啦，有的时候会发现刚毕业的小朋友会将好多的私有变量放在类的顶部，同时一个类里写太多的方法，而且有的方法好长，还没有注释。于是有的时候你想了解一个方法的真正含义，要鼠标各种滚动，到变量声明去了解真正用途，好烦的。

有的时候代码的职责不明确，总是瀑布的思想方式去写代码，比如我们两个功能：一个是发送API请求建立虚拟机，另一个是在虚拟机建立成功时候将操作Log写入db。他们习惯性的将写DB的逻辑放在了发送HTTPRequst的方法里面，这完全是两个逻辑。另一个问题是由于创建虚拟机是需要时间的，同时尽管虚拟机操作成功有可能你写DB的时候网络原因DB失败了。我认为这应该是个原子的操作，两者的状态必须统一，就像是你在手机充值的时候显示银行卡扣金额成功，可是手机充值是出现问题，钱不是白花了吗。所以在这些有特殊逻辑的地方要建立特殊的统一的机制，不能每个人有各自的实现。

之后就是沟通了

由于项目涉及到多个项目组，我们并不是同一个部门，相互也不熟悉，所以沟通上就会有一些需要注意的。首先要了解“对手”，主要是因为如果对方是个技术高手，你不能像个白痴小孩，要有所准备，最起码知道他们用什么开发语言，他们需要关注的业务逻辑，等等，不能让他们得到你是个菜鸟的结论。

由于口头的好多东西可能是没有经过检验的东西，所以前几次达成的协议我们只是做个参考，需要多次沟通之后才能确定结果，比如我们的项目中我们需要和Python组Java组协调消息接口，消息格式的时候。你要知道协调RabbitMQ时候我们需要定义下交互的Exchange，queue name 或者RoteKey等等，同时由于消息格式比较大，需要定义一些关键字或者预设字段的话，需要发邮件进行确认与沟通，避免开发过程中产生误会影响完成的功能返工。

总之这次搭架子的过程收获很多，一时半会也不能想的全面，以后慢慢聊，由于是第一次资历尚浅，好多的技术选型，问题考虑可能不成熟，也希望大家知道更多的能够纠错指导。