泛泛的模块化，SOA等等这些概念，这里不想赘述，这儿更多分享一些实战经验，不限开发语言。
开发中注意事项
1. 线程安全：Coding简单来说就是逻辑性的调用基本库API /开源库的API 及语言基本组成部分(语法、结构、变量、常量、语句、函数等)，给定输入，输出预期输出，因此，编码者应本着对程序负责的态度，仔细阅读你所使用API 文档/API 源码来确定是线程安全的，如果不是线程安全的，要么你没有多线程场景，要么你自己通过线程锁/读写锁机制去保证线程安全，结构同样如此，比如golang map就不是线程安全的。
2. API 限制： API是由使用条件的，比如buffer最大长度等等，这时一定要基于你的应用场景做出合适的处理，是分段处理，还是通过API提供的调整API buffer 最大长度API去加长buffer最大长度，这些均需要你从系统稳定性及性能去考虑选择最优方案，比如kafka系统receive size是由配置文件配置size决定的，你需要了解它的size限制。
3. 资源限制：宿主机的内存，磁盘，打开文件数，带宽等限制，只有清晰的了解资源限制，才可以有的放矢的去解决，或从硬件上扩容，或从软件上做流量控制来保证系统稳定运行。
4. Failover机制: 更多的是一种对错误的一种预防，系统尽可能按照预期稳定运行，即使99.99999%运行稳定率，毕竟还是有fail的几率，怎么办，就是失败预防，无论运行中程序，出错后数据local存储，还是大家提及的灰度部署都可以看做是failover机制。
5. 兼容机制：service API，设计之初就要考虑向前向后兼容，尽量别有broken change，不然这就要靠后续部署机制来保证service downtime, 比如蓝绿部署，灰度发布，滚动发布等，不可避免的会带来一些effort
测试aspects
即使成熟的程序员，也只能避免少犯错误，无法避免不犯错误，怎么办呢？我们可以从以下几个方面去发现错误，修订错误。
单元测试
集成测试
稳定性测试
性能测试
怎么调试hung程序
首先分析系统链，看是哪个环节没有响应，然后基于这个环节进行分析，主要的可能情况为以下几种:
1. 资源不足，比如系统文件描述符耗尽，内存资源不足，cpu满load等
2. 死锁
3. 死循环
可以借助gdb or strace调试工具进行解析
网友评论