摘要：为了给公司供给安稳牢靠且优异的效劳，作为一名软件架构师，在运用的架构规划上也是费尽心思，这篇文章作者来自“风语者客服+”的CTO黄耀华，他从自个多年的实习动身，总结了软件架构规划的一些经历，共享给咱们。
“风语者客服+”是关于中小型公司推出的客服SaaS，节省了公司自建客服体系所需的无穷本钱。为了给公司供给安稳牢靠且优异的效劳，咱们在全体架构上费尽心思。尽管不尽完美，希望借此抛砖引玉，相互切磋。
前语
”Look deep into nature, and then you will understand everything better.“ -- Albert Einstein
中国传统文化上，要做成一件事，考究三个方面：明道，优术，取势。在软件架构规划方面而言，也是类似的道理：遵从自然规律以清晰大的方向，运用优异的实操战术，再依据实践状况落地。
这是个快餐时代，简直一切人都只做一件事 -“取势”。 简直没有多少人会去了解一个Servlet的作业原理，去了解一次HTTP恳求的完好流程，由于有超多结构帮你屏蔽了这儿的细节。问询一自个会啥技术，答复也往往是我会Hibernate、Spring、Ibatis、会PullToRefresh组件、会运用SDWebimage。不过这些结构(Framework)本来并不是软件架构。软件架构是一一切生命力的房子，而这些结构仅仅大一点的板砖。
由于笔者水平有限，这儿只提一些遍及原则，也即是”准确的废话“，以飨视听。不会深化到实操战术上，比方如何用Spring施行MVC架构，如何运用Maven办理依靠，Redis的常用操作，如何建立一个负载均衡的集群，如何运用阿里巴巴的Dubbo结构进行效劳化等等。假设咱们有爱好，能够自行查找，有许多优异的文章可供参阅。
意外的“程序猿”和“程序媛”各有各的苦楚，美好的程序员都是类似的。本来说美好有点言过本来，下面就说说如何让他们不那么苦楚。
一. 极好的模块化支撑
“At the bottom of every person's dependency, there is always pain, Discovering the pain and healing it is an essential step in ending dependency.” --Chris Prentiss
他们都在一个相对安稳的软件架构里编码，自个的代码不会依靠许多模块，不会由于自个细小的改动形成大局的失利。正如"1984"中的老大哥说的，Ignorance is strength(”对外界的“无知即是一种力气). 任何一个模块都不能有太强的存在感。
曾经在一个大型互联网公司里边，任何人只需用到一个中心模块的功用，就有必要依靠一个布置在某长途效劳器的库，并且还有IP约束，只能把代码布置到指定网段才干运转起来。致使基本上无法在本地进行单元测试或许简略调试。这个中心库的存在感太强，就成了开发的瓶颈，严峻的降低了出产力和码农的美好程度。
在“风语者客服+”的架构中，每个码农都能够很便利的在本地把效劳发动起来，一分钟up and running，随意做一些改动就能够马到成功的看到作用。这儿要归功于几个东西：
1. Git代码办理
在团队作战中，每个程序员能够取下来完好的最新代码库，也能够在本地分支上纵情挥毫泼墨，而不忧虑影响他人的作业。也能够把本地修正先stash起来，review一下他人的代码，再unstash康复回来。要想进步团队功率，代码库房办理主张赶快迁移到Git上。
2. Maven、Gradle、Cocopods等依靠办理
Maven是一个办理依靠(Dependency)的东西，如今在Java社区应当是对比遍及的，无法幻想如今还有团队直接复制jar包来办理依靠。尽管前期没有Maven的时分，都是复制jar包这么过来的，碰到的疑问也是清楚明了的，依靠的jar包作者改了某个bug，没能及时传导到调用方。多个调用方运用不一致的jar包，致使各种奇特bug。对应的在安卓社区，运用gradle的对比多，iOS的Objective-C开发中，多选用CocoaPods。
二. 高内聚，低耦合
He should focus on his knitting, not trying to do everything. Do one thing well.-- Steve Jobs
"Do one thing well"本来不算是老乔的专利，UNIX哲学和Google哲学都发起这一点。这句话自身不完全对，比方关于一个商人，假设只会Do one thing well，那他无法在商场中存活，可是在工程师中却是千般推重的哲学。
咱们能够希望一自个具有一百种技术，可是对一个东西只希望它把一个需求处理好处理完全，关于完成东西的一个类，一个办法，更是如此。可是，实践经历中，咱们常常看到一个5000行以上代码的类，酷似一个伟人版的瑞士军刀，啥都能做，可是啥都做欠好。这即是”Separation of Duty"没有做好的模范。
在风语者”客服+“对外供给的SDK和API中，咱们也发起相同的思维，力求把App运用”客服+“SDK的门槛降到最低，每个API都能自言其一，并且API直接没有时序上的依靠联系。内部各个模块的开发，也遵循相同的职责切割原则。职责切割原则的执行，没有啥好的结构或许东西来支撑。只能经过老鸟常常去做Code Review，找出存在的疑问，提出重构计划，并催促菜鸟改善。
自个通常选用的重构思路，仅作为参阅，照搬后被老板批判甚至形成工伤概不负责：
把一个大的东西类，依据主题不一样，拆分红若干个互不搅扰的高内聚东西类;举个比方，一个全能的NetworkUtils或许能够拆成HttpUtils， FTPUtils，TelnetUtils等;
关于一个被频频调用的类，仔细观察调用状况，假设有一些办法的被调用频率远远低于别的办法，那么需求思考这个办法是不是应当放在这个类中;
存在A,B两个类之间的相互依靠，或许更多类的紊乱依靠，那么就更要抽丝剥茧，经过合理安排类的功用来去掉环形依靠;
测验一句话说清楚一个类的功用，不要运用“和”，“以及”，“或许”等连接词;假设呈现了这些连接词，就需求致使注重;
三. 用进化拥抱改变
“It is not the strongest or the most intelligent who will survive but those who can best manage change.” ― Leon C. Megginson
前段时间，朋友圈疯传一篇文章 -——“架构堕落之谜”，咱们都深表同感，纷纷表示对自个架构的将来的忧虑。可是，说句不达时宜的话， 90%的忧虑是杞人忧天，由于以如今商品更新换代的速度，90%的项目面市即意味着逝世，没比及架构迂腐，商品现已入土了。
剩余10%里边，或许有9%会一向坚持活下去，可是不会蓬勃发展，也即是说，只需确保不呈现内存走漏之类的疑问，代码就会一向在几台小效劳器上运转下去，哪怕后边没有人保护也没联系。只要1%的商品，会一日千里的更新迭代，终究生长为巨无霸，或许巨无霸的生态下的一个环节。这个言辞看似失望，却是对实际最佳的退让。
谬用一下泰戈尔的名言：“不是槌的冲击，而是水的欢欣鼓舞，使鹅卵石臻于完美”， 不是凭空捏造的架构，而是不断拥抱改变的需求，才使得架构臻于完美。
假设在前期就纠结于架构的完美性，而推迟商品的交给，是十分因小失大的。只要生计下来，才有时机。再依据商场改变，不断优化架构，然后延伸软件的生命周期。那么，假设撞大运，真的成了这1%，如何做才干算是拥抱改变?
首要，请参阅这篇文章第一点和第二点。假设这两点基本功没有练好，那么谈架构的进化就和还没有通关十八罗汉的菜鸟就想练成九阴真经是一个道理。
在规划之初，开始思考体系的Scalability(可伸缩性)
下面在第四点会具体论述。
内部的各个模块尽量做到可插拔
一方面是接口和完成的别离，能够跟着需求的改变替换完成;另一方面，尽量把功用效劳化，变成微效劳，并且能够监控到效劳的相互调用状况，当某个效劳老化，能够逐渐抛弃或运用新的效劳替代之。这一点上，阿里巴巴的Dubbo结构是一个不错的挑选。
尽量选用优异的结构，站在伟人的膀子上
例如在Web层面，咱们运用Twitter的Bootstrap前端结构来完成呼应式Web编程，进步出产功率的一起削减了为处理各种设备适配疑问的投入。当然，这就需求规划师合作，依照Bootstrap标准来规划页面，削减一些个性化规划。
最终，思考体系的Resilience(弹性，也叫耐受性)
俗一点说，即是变成一只打不死的小强，代码中尽量提早预判或许遇到的各种景象。常常看到代码里边有成堆的if(){}判别句子，我就问作者，“你思考过else{}吗?”通常答复都是，“这肯定只要if，不会有else的”，可假设真的遇到else如何办?千年虫疑问即是这么诞生的。或许许多新同学还不知道啥是千年虫疑问，简略地说，即是当年的码农，为了省一点内存空间，只用了2位数来表达年份，比方int year = 98; 表达1998年。我猜码农其时的心态也是，“就我这代码，还能活到2000年，搞笑吧?”
程序员们平常能够多拓展自个的脑洞，想想有哪些else状况自个没有处理，并且能够容易处理的。比方效劳器挂了，那么App端是不是也要跟着crash，仍是给出友爱一点的提示，或许更友爱一点，运用本地缓存。
四. 规划可拓展，但不要过度规划
it's better to have infinite scalability and not need it, than to need infinite scalability and not have it--@littleidea 网友
无限的拓展才能是一种奢求，可是最少不能让拓展才能变成0。试想一下，你辛辛苦苦为老板开发了一个网站，过了一个月，网站超负荷了，老板说，“小A啊，之前2台效劳器花了我5万块，估计流量立刻要翻倍了，再给你5万块，帮我扛过去啊。”成果你发现，疑问不是线性添加效劳器就能处理的，本来的程序没有做分层(Web，Business Logic， Data Access等)，致使加效劳器也只能把一切层的代码全搬到新的效劳器，尽管仅仅Business Logic的核算有压力，却要糟蹋老板许多效劳器。更差劲的是，由于程序里边用到了文件体系和操作体系指令，欠好做负载均衡。
这儿有一些原则供参阅：
代码分层是有必要的，层次明亮今后，当哪个层次的负载较重，想办法对该层次进行优化或许扩容即可;
坚持中心效劳是无状况的，所谓无状况即是没有和恳求有关的数据依靠;
尽或许的选用已被验证的广泛选用的老练根底架构;
充分利用Zookeeper等集群办理东西，来对效劳进行办理;
风语者“客服+”中，把事务有关的代码内部组装为风语者ServiceBox，运用阿里巴巴的Dubbo效劳进行注册办理。当负载添加时，能够敏捷在运维层面添加效劳节点，以供给更高的效劳才能，然后确保客户的优异体会。
（PHP培训机构）
