前言我在过去的两个月里一直在深度参与分布式系统的开发。记得之前有人说过“想成为架构师之前，先从微架构做起”。虽然我从来没有想过将来有朝一日成为一名架构师或者领域专家，只是想乖乖的编码，写出自己喜欢的代码，和一群志同道合的朋友一起做出大家喜欢的产品和产品。但是工作久了，慢慢摆架子的事情还是会来找你，因为时间总会慢慢把一些人推向海边，让他们最先见到太阳。废话不多说，我为什么说阳光，因为过去的两（三）个月可能太充实也太痛苦了。完成之后，当黎明来临的时候，整个人都会发光。之所以“深度”参与，是因为我终于有机会在搭建货架的过程中拥有话语权和选择权，同时我还将承担70%以上的编码工作。我之前的自我认知是，我在软件方面的积累可能还可以，比如设计模式、架构分层、程序解耦、API入门等，但总觉得自己在硬件和网络方面的积累太少太单薄。例如：不同操作系统的特点；网络端口管理和分配；哪些网络协议可以帮助我们更好的完成工作，在监控虚拟机的时候，应该给虚拟机加代理还是使用协议来控制；硬件是否支持Distributed，扩展过程中如何兼容.netC#；什么时候使用多线程，我们在将线程交给程序调度时，如何控制和捕获线程异常；日志系统对整个去中心化系统有多重要？何时使用关系型数据库，何时使用Nosql；是否使用MSMQ或RabbitMQ作为消息队列；如何与其他部门的同事进行有效的沟通；如何有效地调度以不同语言开发的系统；大型测试用例系统从零散到完整有多重要；系统标准和代码原则对于后期的维护和扩展有多重要；ETC。;协调其构建的私有云和其购买的公共云的系统。有一件事要说很棒：混合云系统。使用Restful是构建整个系统的最好成绩。以往使用webapi的经验只是为电商系统的移动端提供数据交互接口。但是做完这个项目，发现Rest接口不仅仅是一个对外系统提供的交互方式，一些开源工具暴露出来的接口也是基于rest的，可见全世界的程序员是多么热爱json休息；为什么以前的开发经验安装配置好软件后就不能用了？由于使用了所有Microsoft技术，包括组件和工具。但是在项目中使用了一些开源工具后，配置成功后无法运行。同时，由于开源工具对Exception进行了封装，我们很难知道到底是什么问题。有时候调试了很久还是不能运行，非常沮丧和恼火，原来是因为公司IT只开了常用的端口，其他的都被kill掉了。申请开放端口是要走流程的，所以有时候对于开发者来说外网开发虚拟机也是相当有必要的。使用RabbitMq我个人非常喜欢使用Mq。在做电商之前，总喜欢在Application层下面放一层Service。你不需要它，但你总是像强迫症一样不写它。为什么不使用Msmq？原因有很多。简单点就是rabbit是比Msmq更高级的协议，支持更多的处理功能。最重要的原因是Rabbit在开源语言的使用上处于领先地位，而我们的系统不得不嫁接太多的开源语言系统，只能适配。我知道Mq经常用于企业系统之间的数据交互。不仅可以有效划分层次，解耦依赖，而且在数据交互方式上也相当方便。总会有消息没有被消费者使用，那么我们就需要程序异步处理消息队列。Redis系统使用了三种数据存储，MySql、SqlServer、Redis。当然，前两者适合开源和C#，使用Redis是针对那些总是很难找到有效关系和依赖关系的数据。例如，我以前只认识Reids。可以作为数据存储，分布式，主从复制，但是经过这次开发，我真的发现Reids或者Nosql很难掌握一个数据规则，对于一个数据量很大的系统来说是多么的重要，因为有时候一批Json序列化后，很难有效的挖掘出里面的关系和逻辑，所以干脆一次性放到Redis中，使用的时候把顺序倒过来。同时，我们确立了读写分离的原则。我们主要是把读取放在Redis中，写入到Mysql中，通过Mysql触发器实现server段数据的主从复制同步。当我们在没有日志系统之前是单系统的时候，比如只是一个简单的3层架构，我们可以通过Debug从头调试到数据库，每一步都在我们的掌控之中，我们可以有一个每一步都尽收眼底。但是，对于一个太深、调用次数多、同时是多线程的系统来说，挖矿的机会、时间、成本都要综合考虑。因此，有效地使用日志组件，有效地在代码中挖掘地雷，就显得尤为迫切和必要，可以更好地帮助我们发现问题所在。#p#组件化开发之前的简单分层系统我们使用svn或者其他代码管理工具，Merge可以看到每次提交，但是当系统复杂，系统非常独立的时候，分成组件和模块开发就变得很重要的。因为不想把大家的时间浪费在Merging上，所以我们习惯性的每周2号都有自己的Branch提交代码，大家一起参与，这样就减少了很多浪费在代码管理上的时间。测试用例之前，小系统use测试用例基本都是用来安装B的。本来小系统的整个过程想想就知道怎么做了，何必浪费时间。然而，在这次开发中，测试用例的重要性得到了充分的理解。比如我需要你给我提供多台服务器的监控数据，包括CPU信息，IO信息，NEt信息等等，但是你还没有想过怎么抓取虚拟信息，不能影响其他人的进步是因为你的问题，最好的办法是从用户的角度知道他想使用什么样的数据，为它创建一个API，同时为API创建测试用例并确保测试稳定。后期我有了监控虚拟机的方法后，我会建立相应的适配方法去适配相应的API。所以首先我们要保证API的稳定性，因为如果它上面的东西已经稳定了，你还得下功夫。有效的测试用例可以帮助我们更好地分离项目逻辑，协调组件系统。coding的原则是每个人每周都有时间参加CodeReview。由于开发人员的能力和资质不同，在代码编写和建立过程中总会存在太多不一致的地方。比如命名，变量声明，有时候你会发现刚毕业的孩子会把很多私有变量放在类的最上面，同时一个类里面写的方法太多，有些方法很很长，没有评论。所以有时候你想了解一个方法的真正含义，还得滚动鼠标到变量声明处才能了解真正的用途，这很烦人。有时候代码的职责不明确，总是用瀑布式的思路写代码。比如我们有两个功能：一个是发送API请求创建虚拟机，另一个是虚拟机建立成功后，将运行日志写入db。他们习惯性的把写DB的逻辑放在发送HTTPRequest的方法中，完全是两种逻辑。还有一个问题是创建虚拟机需要时间，而且即使虚拟机运行成功，也有可能你写DB的时候因为网络原因DB失败了。我觉得这应该是一个原子操作，两者的状态一定要统一，就像你给手机充值的时候，显示银行卡扣款成功，但是手机充值有问题电话，钱也没有浪费。所以，在这些逻辑特殊的地方，必须建立特殊的统一机制，不能每个人都有自己的实现。之后就是交流了。由于项目涉及多个项目组，大家不在一个部门，彼此也不熟悉，所以在沟通中会有一些需要注意的地方。首先，你要了解“对手”，主要是因为如果对手是技术高手，你不能像个白痴孩子一样，你要有所准备，至少知道他们用什么开发语言，业务逻辑他们需要注意什么等等，你不能让他们得出你是菜鸟的结论。由于很多口头的东西可能没有测试过，所以前几次达成的协议只是参考，需要多次沟通结果才能确定结果。比如在我们的项目中，需要和Python组、Java组协调消息接口。,当消息格式。你要知道，在协调RabbitMQ的时候，我们需要定义交互的Exchange，队列名或者RoteKey等，同时由于消息格式比较大，如果需要定义一些关键字或者预置字段，就需要发送邮件进行确认和沟通，避免开发过程中的误解影响完成的功能返工。总之，这次摆架子的过程让我收获颇丰，一时想不通。以后慢慢讲。由于是第一次，资格还年轻，技术选型比较多，对问题的考虑可能还不成熟。希望大家知道更多的纠错指导。以下是我们在架构中使用的一些东西：开发语言：C#、java、Python；数据存储：缓存、文件（xml）、MSsql、Mysql、Redis；数据交互：rest、json、RabbitMq；操作系统：ubuntu、windows；虚拟机监控：zabbix；搜索：solr；多线程、多层架构、模块化开发、组件化开发；本文来自：http://www.cnblogs.com/xiguain/p/3839944.html
