随笔分类 - 系统架构设计
摘要：
进入直播领域有段时间了。
跟大多数同学一样，刚接触直播这个领域都非常好奇这个领域的宏观架构大概是什么样子的。
这里根据自己的这段时间学习，粗浅总结下分享给感兴趣的小伙伴扫扫盲。
目前直播平台有很多，抖/快、B站、斗/虎等。
直播这种高效的交互方式是各行业需要具备的能力，随着网络技术的发展也是必然趋势。
阅读全文
进入直播领域有段时间了。
跟大多数同学一样，刚接触直播这个领域都非常好奇这个领域的宏观架构大概是什么样子的。
这里根据自己的这段时间学习，粗浅总结下分享给感兴趣的小伙伴扫扫盲。
目前直播平台有很多，抖/快、B站、斗/虎等。
直播这种高效的交互方式是各行业需要具备的能力，随着网络技术的发展也是必然趋势。
阅读全文
摘要：
要想db操作的性能足够高，巧妙的设计很重要，事务的操作范围要尽量的小。一般情况下我们都是使用某个orm框架来操作db，这一类框架多数的实现方式都是夸网络多次交互来开启事务上下文和执行sql操作，是个黑盒子，包括对 autocommit 设置的时机也会有一些差异，稍微不注意就会踩坑。 在大并发的情况下
阅读全文
要想db操作的性能足够高，巧妙的设计很重要，事务的操作范围要尽量的小。一般情况下我们都是使用某个orm框架来操作db，这一类框架多数的实现方式都是夸网络多次交互来开启事务上下文和执行sql操作，是个黑盒子，包括对 autocommit 设置的时机也会有一些差异，稍微不注意就会踩坑。 在大并发的情况下
阅读全文
摘要：
背景 通过脚本改变评分 背景 近期有一个需求，需要对优惠券可用商品列表加个排序，只针对面值类的券不包括折扣券。 需求是这样的，假设有一张面值券 50 块钱，可用商品列表 A 100、B 40、C 10，当用户查询当前券可用商品列表的时候优先将卡券可以直接抵扣且不需要用户在额外支付的商品排在前面。 C
阅读全文
背景 通过脚本改变评分 背景 近期有一个需求，需要对优惠券可用商品列表加个排序，只针对面值类的券不包括折扣券。 需求是这样的，假设有一张面值券 50 块钱，可用商品列表 A 100、B 40、C 10，当用户查询当前券可用商品列表的时候优先将卡券可以直接抵扣且不需要用户在额外支付的商品排在前面。 C
阅读全文
摘要：
背景 症状 排查 修复 背景 最近在陆续做机房升级相关工作，配合DBA对产线数据库链接方式做个调整，将原来直接链接读库的地址切换到统一的读负载均衡的代理 haproxy 上，方便机柜和服务器的搬迁。 切换之后线上时不时的会发生 discard connection 错误，导致程序报 500 错误，但
阅读全文
背景 症状 排查 修复 背景 最近在陆续做机房升级相关工作，配合DBA对产线数据库链接方式做个调整，将原来直接链接读库的地址切换到统一的读负载均衡的代理 haproxy 上，方便机柜和服务器的搬迁。 切换之后线上时不时的会发生 discard connection 错误，导致程序报 500 错误，但
阅读全文
摘要：
从 __SOA__ 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性，系统调用带来的一致性问题，还是跨节点跨机房复制带来的一致性问题都有了很多解决方案），但是有一个环节我们明显忽略了。
在现在的微服务架构趋势下，微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看，上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。
阅读全文
从 __SOA__ 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性，系统调用带来的一致性问题，还是跨节点跨机房复制带来的一致性问题都有了很多解决方案），但是有一个环节我们明显忽略了。
在现在的微服务架构趋势下，微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看，上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。
阅读全文
摘要：
最近一段时间公共业务平台在进行大面积的重构，对原来的技术栈进行迁移，逐渐往java、go、node.js等开源、自由为主的技术体系中过度。
虽然这主要是替换技术框架，但也是我们应用系统进行重新设计、业务流程重新梳理的一个好机会，我们将利用这次机会来重构之前发现的一些问题。
Martin Fowler大师《重构》一书中有说过一句话，大概意思就是，“每次对原有系统进行修改调整的时候是一个非常好的重构契机。”
阅读全文
最近一段时间公共业务平台在进行大面积的重构，对原来的技术栈进行迁移，逐渐往java、go、node.js等开源、自由为主的技术体系中过度。
虽然这主要是替换技术框架，但也是我们应用系统进行重新设计、业务流程重新梳理的一个好机会，我们将利用这次机会来重构之前发现的一些问题。
Martin Fowler大师《重构》一书中有说过一句话，大概意思就是，“每次对原有系统进行修改调整的时候是一个非常好的重构契机。”
阅读全文
摘要：
从事.NET开发到现在已经有七个年头了。慢慢的可能会很少写.NET文章了。不知不觉竟然走了这么多年，热爱.NET热爱c#。突然想对这一路的经历进行一个总结。 是时候开始下一阶段的旅途，希望这些文章可以在发挥点价值作用。 架构设计： ElasticSearch大数据分布式弹性搜索引擎使用 （推荐） D
阅读全文
从事.NET开发到现在已经有七个年头了。慢慢的可能会很少写.NET文章了。不知不觉竟然走了这么多年，热爱.NET热爱c#。突然想对这一路的经历进行一个总结。 是时候开始下一阶段的旅途，希望这些文章可以在发挥点价值作用。 架构设计： ElasticSearch大数据分布式弹性搜索引擎使用 （推荐） D
阅读全文
摘要：阅读目录： 背景 安装 查找、下载rpm包 、执行rpm包安装 配置elasticsearch专属账户和组 设置elasticsearch文件所有者 切换到elasticsearch专属账户测试能否成功启动 安装自启动elasticsearch servicewrapper包 下载elasticse
阅读全文
阅读目录： 背景 安装 查找、下载rpm包 、执行rpm包安装 配置elasticsearch专属账户和组 设置elasticsearch文件所有者 切换到elasticsearch专属账户测试能否成功启动 安装自启动elasticsearch servicewrapper包 下载elasticse
阅读全文
摘要：
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
摘要：
这篇文章内容会很短，主要是想给大家分享下我最近在做一个简单的rabbitmq客户端类库的封装的经验总结，说是简单其实一点都不简单。为了节省时间我主要按照Library的执行顺序来介绍，在你看来这里仅仅是一个简单的经验总结，但是在我看来这些经验只有在你真正的封装rabbitmq客户端库的时候且将你的客户端安全稳定的发布上线后才会真的发现这些问题。
比如你的库只是链接单个Node的时候和链接高可用集群的HAProxy时候是完全两回事。当你未能在你的库里使用反向注入LOG接口的时候一旦在线上发生网络解析和序列化等一系列在线问题时候你是多么无能为力。当你使用同步循环获取队列消息的时候一旦发生异常你的链接就会断掉等等这些细节。我总结了我在编写这个library的时候慢慢稳定下来的过程和经验。至少目前来看网络上的文章，当然我是指.NET/C#方面的，都没有讲到这些问题，大
阅读全文
这篇文章内容会很短，主要是想给大家分享下我最近在做一个简单的rabbitmq客户端类库的封装的经验总结，说是简单其实一点都不简单。为了节省时间我主要按照Library的执行顺序来介绍，在你看来这里仅仅是一个简单的经验总结，但是在我看来这些经验只有在你真正的封装rabbitmq客户端库的时候且将你的客户端安全稳定的发布上线后才会真的发现这些问题。
比如你的库只是链接单个Node的时候和链接高可用集群的HAProxy时候是完全两回事。当你未能在你的库里使用反向注入LOG接口的时候一旦在线上发生网络解析和序列化等一系列在线问题时候你是多么无能为力。当你使用同步循环获取队列消息的时候一旦发生异常你的链接就会断掉等等这些细节。我总结了我在编写这个library的时候慢慢稳定下来的过程和经验。至少目前来看网络上的文章，当然我是指.NET/C#方面的，都没有讲到这些问题，大
阅读全文
摘要：最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。
软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。
不能用好与不好来判断哪一种方法论，只能根
阅读全文
最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。
软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。
不能用好与不好来判断哪一种方法论，只能根
阅读全文
摘要：随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。
但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。
但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。
阅读全文
随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。
但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。
但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。
阅读全文
摘要：一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。
在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都..
阅读全文
一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。
在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都..
阅读全文
摘要：对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。
DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。
阅读全文
对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。
DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。
阅读全文
摘要：接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。
我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。
阅读全文
接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。
我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。
阅读全文
摘要：现在越来越多的公司都在尝试SOA架构的实践，本人最近也在尝试学习这方面的技术，但是在实践过程中遇到一个问题，我想这个问题也是我们普遍实践者都应该会遇到的问题，问题描述如下： 我们有一个SOA商品（Item）查询接口，这个接口很通用，主要用来支撑日常很多其他系统的大量关于Item的查询，尤其是在高峰期间该服务的压力是很大的；我们站在SOA的角度看这个接口，这个通用的接口解决了众多的查询业务，确实不错，但是我们切换一下角度，站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价，因为我们无法干净利落的只获取当前这个业务点需要的数据项；这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点，哪怕这次调用我只需要用到Item的三分之一的数据字段都不行，每次都会把不需要的字段都查询出来，不管是返回的性能、查询的性能，其实都是可以通过调整设计来避免的；
阅读全文
现在越来越多的公司都在尝试SOA架构的实践，本人最近也在尝试学习这方面的技术，但是在实践过程中遇到一个问题，我想这个问题也是我们普遍实践者都应该会遇到的问题，问题描述如下： 我们有一个SOA商品（Item）查询接口，这个接口很通用，主要用来支撑日常很多其他系统的大量关于Item的查询，尤其是在高峰期间该服务的压力是很大的；我们站在SOA的角度看这个接口，这个通用的接口解决了众多的查询业务，确实不错，但是我们切换一下角度，站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价，因为我们无法干净利落的只获取当前这个业务点需要的数据项；这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点，哪怕这次调用我只需要用到Item的三分之一的数据字段都不行，每次都会把不需要的字段都查询出来，不管是返回的性能、查询的性能，其实都是可以通过调整设计来避免的；
阅读全文
摘要：这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了； “钝化语句” 简单描述：将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用；
阅读全文
这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了； “钝化语句” 简单描述：将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用；
阅读全文
摘要：通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看，对于框架设计的技巧还是有很多人比较有兴趣的，那么框架设计思想对于我们日常开发来说其实并不是很重要，但是对于我们理解框架背后的运行原理至关重要；当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型； 从一开始学习.NET我就比较喜欢框架背后的设计模型，框架提供给我们的使用接口是及其简单的，单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解，反而会养成一样拿来即用的习惯，我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标；因为框架的内部设计模式是可以提炼出来并被总结的； 这篇文章总结了几个我最近接触的框架设计思想，可以称他们为模式；由于时间关系，这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架
阅读全文
通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看，对于框架设计的技巧还是有很多人比较有兴趣的，那么框架设计思想对于我们日常开发来说其实并不是很重要，但是对于我们理解框架背后的运行原理至关重要；当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型； 从一开始学习.NET我就比较喜欢框架背后的设计模型，框架提供给我们的使用接口是及其简单的，单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解，反而会养成一样拿来即用的习惯，我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标；因为框架的内部设计模式是可以提炼出来并被总结的； 这篇文章总结了几个我最近接触的框架设计思想，可以称他们为模式；由于时间关系，这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架
阅读全文
摘要：本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题； 后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为
阅读全文
本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题； 后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为
阅读全文
摘要：在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文
在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文