看一下工程师和架构师的区别，简单地，工程师关注的是功能和代码性能，而架构师关注的是业务和系统的性能等非功能性约束。全栈不是全能，只要覆盖了所使用的技术栈就是全栈，例如LNMP，Linux＋Nginx＋Mysql＋PHP。全栈架构师关注的是业务所采纳的全部技术栈，以及技术栈所涉及的系统性能、安全，高可用等诸多因素。
全栈（full stack developer）好像起源于facebook中对工程师的一种称谓，全栈架构师估计是老曹的杜撰。全栈的出现大概有4个方面：系统的性能瓶颈定位，团队间的沟通障碍，业务的救火灭火，以及团队的资源紧张。尤其的小型创业团队，战力的有限会导致全栈的产生。
和习武一样，我想试图探讨一下全栈的套路，很多能力不是通过当头棒喝产生的。郭大侠需要降龙十八掌，令狐冲以无招胜有招也需要独孤九剑。我觉得全栈的技术栈可以主要分为3个切面：技能，性能 和效率。下面逐一简要阐述：
工其事必利其器，环境在效率中是第一位的。具体可看《老曹眼中的开发学习环境》，不在赘述。
全栈应该掌握4种编程语言：Java，Objc/C/C++, Python，JavaScript。 语言没有优劣，不同语言有各自的胜场。
每个人都不是一个人在战斗，团队敏捷是整体效率的关键。可以使用Trello或worktile之类的工具做协同，以Jinkens等工具支持CI或者CD，了解Scrum中什么是backlog，什么是UserStory，如何控制sprint。同时，敏捷不是以质量的丧失为代价的。
再进一步，就是devops了，可以参考《DevOps 全栈必备双刃剑》。
数据是系统的核心，必须要了解文件系统，对象存储和关系型数据库，只有NoSQL至少要关注redis和mongodb，更多可以可参考《NoSQL与大数据》。
网络是一个覆盖更广的领域，至少要了解七层协议模型，DNS，TCP/IP，HTTP，以及网络类型对网络编程的影响，会上只有简单举例，以后择机仔细探讨一下。
框架和库使用与所采用的语言是息息相关的，不同语言又有着不同的框架与库，简直是浩如烟海，对框架与库的选择主要从面相领域和面向场景入手，有比较才能有选择。
安全是个与非门，没事一切都好，有事就是大事。基本上，可以从传输，网络，代码和数据四个层面掌握有关安全的基础知识。
至于架构方法，现在最热的莫过于微服务架构了。服务的划分与业务密切相关，服务独立后要考虑服务的发现和服务间的通信，最后是服务治理，可以从这四个方面专研相关的技术。
云服务的出现使得小团队可以做大事情，关于混合云的解释可参考老曹的旧文《理解一下混合云》。
从趋势来看，大数据必将成为工程师团队的重要战力，包括专业知识，数学算法，计算环境三个方面。就计算环境而言，涵盖了Hadoop的生态圈，如果只有一个必备技能，老曹觉得就应该是Spark了，可以参考《架构大数据应用》旧文。
个人以为，性能在诸多非功能性约束中第一重要，直接影响用户体验。首先要从业务和代码层面保障性能，而单元测试是一个必要条件。正像PingCAP CTO 黄东旭所说的，“talk is cheap， show me the tests."
接下来是运行时调优，或者认为是单机性能。从加载和依赖开始，到 JVM调优，再到Linux 内核参数调优。 对于 JVM 调优，给朋友做个广告，中生代技术群中的 江南白衣 （公众号：春天的旁边）有一篇干货文章，特别向大家推荐。
数据库是整个系统中的慢性子，关注系统的性能，日志分析比不可少，LEK可能是第一首选。数据访问必须是高可用的，数据连接池的选择和使用都是考验功夫的。
缓存是减少负载，提高系统性的必备技术。可以从客户端，网络侧，服务端三个环节对缓存进行分类，具体可以参考《老曹眼中的缓存技术》。
传输的性能可以依靠消息队列来提升，ZeroMQ可以用在系统内，而ActiveMQ是Java 程序猿的福音，对于高并发和高容错而言，RabbitMQ可能是不错的选择，Kafka是大量数据的传输必备。
啰哩啰嗦，只是想探讨一下全栈的套路，也许这本身就是一个伪命题。
分享者简介：曹洪伟，全栈工匠一枚，现就职于和创（北京）科技股份有限公司。