全栈工程师的意义
全栈指的是同时“懂得”前端与后端的人，而不是说同时拥有开发过前端、后台经验的程序员。
举个例子：
前端开发人员使用nodeJS或者PHP搭建了一个后台服务器，这不是全栈，这只能是“全能开发”程序员。
“懂”指的是，既懂得前端设计思想、又懂得后端建设思路，还懂得前后端之间联系的人。
这句话还得从以下方面进行理解。
先从全栈工程师的诞生原因——前后端分离说起。
前端与后台分离，除了方便分工开发、分别部署外，最大的影响面是前后端数据的绑定关系被切断了。
举个例子：
使用过struts或者原始JavaBean等，都知道后台代码里的变量可以在某种意义上与前端代码里的变量做绑定，后台的数据一更新，前端就自动反应出来的MVC机制。这是一种前后端一体的MVC。
MVC模型图
而前后端分离的架构设计，不单单是前后端的代码分离，也切断了这层绑定关系。
现在的前端使用Ajax（Asynchronous JavaScript and XML）异步调用机制，向后台发送消息，获取页面展示数据。
催生了前端自己的“MVC机制“React.js、Backbone.js，还有后续的MVVM，如AngularJS、Vue.js、Knockout.js、Avalon.js、Ember.js 等前端框架，将后台反给前端的数据与展示用变量做绑定，使得与后台接口通信获得的更新数据直接能同步显示在页面上。
对比一下
前后端分离前：
分为：数据从数据库取出并加工模块、数据展示绑定更新模块。
前后端分离后：
分为：数据从后台获取并加工模块、数据展示绑定更新模块。
前端进入独立发展阶段：
更加注重“展示信息—接受操作—反馈结果”这三个与用户交互层面的功能。
随着PC、PAD、手机等的CPU、内存性能爆发式提高，前端也开始可以拥有图形/图像处理、AR、VR展示，甚至还能做视频处理。
除了自身的主要功能更加完善外，还需要处理一些原本不需要关心的问题，比如代码打包、构建；与后台的数据通信、交互；代码热更新等问题。
注：Ajax最早是微软在1998年开发了核心技术，包含在期 Exchange Server组件中，并且迅速地成为了 Internet Explorer 4.0 的一部分。（我在十几年前看过的.net书籍里，曾经在com组件中见过Ajax。）后来，到了2005年被Google推向高潮。Ajax 这个词由《Ajax: A New Approach to Web Applications》一文所创。
前端发展出专业打包工具Webpack、browserify；构建工具Grunt、Gulp.js；
智能手机的崛起，Android、iOS两大格局形成，催生React Native的诞生。
后台进入双抗化阶段：
（顺应市场要求，向着“抗高并发、抗高流量压力”的方向发展）
在切断了直接绑定数据的情况下，前后端的访问、通信就需要有解决方案支撑，API网关得到了迅速的发展。
传统SOA下的ESB适合系统间交互，但面对海量前端用户发起的冲击则无法抵抗。（因为天生就不是为了这个目的设计的）
ESB结构图
API网关访问图
API网关结构图
API网关的实现方案
Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Tyk 是一个基于Go实现的网关服务。
Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。
Orange：和Kong类似也是基于OpenResty的一个API网关程序，是由国人开发的。
Zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。可以和 Eureka、Ribbon、Hystrix 等组件配合使用。
apiaxle: Nodejs 实现的一个 API 网关。
api-umbrella: Ruby 实现的一个 API 网关。
Nginx(engine x) 是一款轻量级服务器反向代理服务器。
在API网关打发展之后，各项系统服务为了适应高流量、高并发的场景，单体式应用已经扛不住了，催生了微服务，这种分布式系统设计。
微服务的方案也有多种：
一、基于网关的代理端的方案
二、客户端的方案
代表有Dubbo、Spring Cloud等。
SpringCloud是在 Spring Boot 基础上构建的，用于快速构建分布式系统的通用模式的工具集。使用 Spring Cloud 开发的应用程序非常适合在 Docker 或者 PaaS 上部署，所以又叫云原生应用。
三、Sidecar
在微服务领域有Service Mesh的新概念，符合Service Mesh的Linkerd 也提供了负载均衡、熔断机器、服务发现、动态请求路由、重试和离线、TLS、HTTP 网关集成、透明代理、gRPC、分布式跟踪、运维等诸多功能，功能是相当全了，为微服务框架的技术选型又增加了一个选择。基于 Sidecar 模式的 Service Mesh 是云原生架构的更好的实现方式，零侵入和无中心化使得 Service Mesh 倍受推崇。
微服务还发展了内存数据库（Cache）的应用，FastDB、Memcached、Redis等。
而后台也更加注重数据库（包括内存数据库）、应用服务拆分与组合、多线程、服务之间的通信等性能升级上。
服务之间的通信技术包括：
同步调用：
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
异步消息调用(Kafka, Notify, MetaQ)
数据库方面：
Database Mesh，一个搭乘 Service Mesh 浪潮衍生出来的新兴词汇。顾名思义，Database Mesh 使用一个啮合层，将散落在系统各个角落中的数据库统一治理起来。通过啮合层集中在一起的应用与数据库之间的交互网络，就像蜘蛛网一样复杂而有序。
Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。
使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。
微服务和云原生
云原生可以简单理解为面向云环境的软件架构。微服务促进了云原生，从而促进了Docker这类容器化技术的发展。
容器化组件集合：
编排和调度：kubernetes、Docker Swarm、Mesosphere DC/OS、Amazon ECS、Azure Container Service、Google Container Engine、Cloud Foundry's Diego、Marathon、HashiCorp Nomad、Helios、Rancher、Nebula。
持续集成/持续部署：Jenkins、CircleCI、Travis CI、CodeShip、GitLab CI、Shippable、CodeFresh、Buddy、Drone、Wercker。
监控：Sumo Logic、Prometheus、Sysdig、Sysdig Monitor、Datadog、New Relic、cAdvisor。
记录：Logspout、Fluentd、Logstash、syslog-ng。
安全：Clair、Aqua Security、Twistlock、Docker Bench for Security、Docker Notary。
存储/卷管理：Convoy、Portworx、Blockbridge、Flocker。
联网：flannel、Weaveworks、Project Calico。
服务发现：Consul、Etcd、Proxy。
构建：Packer、Whales、Gradle。
管理：Portainer、
云计算是一种商业模式
什么是云计算么？节约成本？虚拟化技术？
归根结底，那是一种商业模式。
软件易被破解、被盗版，使得研发投入与商业回报不相匹配。
如果，软件跑在云端，就不存在被盗版的风险，还能获取客户数据等好处。最早，就是这个目的。所以，它的出现是一种商业考量。但后来，随着云所提供的服务越来越多，越来越复杂，降低企业的IT成本成了云的主打竞争力。云是软件业的未来，对整个软件业的健康发展都是有益的。但市场是否接受，这是一个很大的问题，要考虑客户的诉求，毕竟如果客户不买账，基本上商业模式就宣告失败了。
亚马逊因为服务器买多了才搞成云租给别人用，Google因为使用大量开源软件不公开源代码、不遵守GPL等开源协议的要求被告了，才搞到云上去提供服务。虽然，开端都不咋样光彩，但后面的其他云都还是不错的。所以，云是软件的另一种商业模式，光是搭建一个云平台是毫无意义的，上面提供的服务才是云的价值。云所提供的服务不是单一的，而应是涵盖整套商业战略的软件供应，缺一不可，否则就没有上云的意义。也就不符合客户的需求，自然就没有市场。
云服务平台最大的资源是众多的企业客户，除了获取数据以外，其最大的优势是一个流量入口，企业有客户，云平台有企业，也就拥有了客户，而且可以给新来的云客户企业做导流，促进企业间互相合作。云平台之间也可互相打通某些方面的合作，比如视频云、游戏云与金融云、财务云合作，将双方的企业客户更加粘合在自己的平台上，提供全方位的服务。
所以说只是做过前端和后台的开发，而不理解前后端设计思想的人，不是全栈。
有一种言论说“在大公司不需要全栈，因为大公司分工明确，不需要程序员即开发前端又去开发后端。”
很明显，这是把全栈误解成之前说的“全能开发”了。
全栈在大公司有很重要的作用，一般往往由技术架构师兼任，来协调前后端的统筹设计。
单纯的前端技术架构与后台技术架构两职能分离，会产生一些问题。
比如，功能如何分配
有些需求在前端与后台都能实现，有些甚至要前端后台共同商讨策略才能实现，如何划分、如何联系，这需要全栈来评估和出方案。
举个例子：
之前的开发中，遇到一个二维码海报的需求。
而生成海报的功能是放在前端做，还是后台做就有了两种方案。
方案一：放在后台，用Java实现二维码生成和微信头像与海报背景的三层图片合成，Java代码有现成的可供参考，并且最终合成的图片只需给前端展示引用，对前端来说非常方便。
优点：技术实现难度小，代码运行稳定，对图片流base64格式支持较好。
缺点：非常明显，对服务器压力会很大，存在大量缓存在服务器上吃资源，并且Java生成图片速度比较慢，会造成长时间占用链接，导致网络拥堵。
方案二：放在前端生成，用js写，使用HTML5中最新的标准去合成图片。
优点：不占后台资源（所有合成图片的计算都在前端，占用用户手机的资源）也不占用后台响应时间，都在前端处理。
缺点：技术难度大，js没有现成的库可以使用，必须从底层改写二维码生成库和图形库。
而往往前端和后台的开发人员就开始互相扯皮，踢皮球，更别提在共同商讨策略时在鸡同鸭讲了，甚至最后实现不了需求。
全栈工程师与技术架构师的区别与联系
区别：看待问题的角度不同
全栈是从前后端的角度去看问题，而技术架构师是从全局去看待问题。所做的分析面和广度不一样。
联系：全栈是通向技术架构的必经之路
技术架构师拥有技术栈的统筹能力，必须拥有全栈能力，否则就是耍流氓，只能称为后台架构。
相同点：
全栈工程师能预测技术的未来发展，这点也是技术架构师必备的技能。
对未来技术的预测能力：
光做开发是无法预测技术的未来发展的，只要留意现在的技术发展、框架发展就会发现，技术往往为适应需求而发展，使得整个技术组合、框架组合协同更新。这就需要你懂得设计思想才能做预测，光是开发过而不懂设计思想，是做不到这一点的。
另外，技术架构不单单是选型、研发组件。还有对可能出现的问题进行风险控制。对能遇见的问题，如无法避免，就要有配套的解决方案，在开发中如若发生，就能让开发人员顺着解决方案去解决，有办法可循。而不是简单写一下大体框架性代码、搭建一个环境就开工了。