学习基础：
Architecture，做架构的人就是大名鼎鼎的架构师！但和CEO一样，本身其实没有意义……
我们这里所讲的架构，指的就是Web企业应用的架构。本质上来说，它仍然是对代码的组织管理，但更加的宏观和全面。架构可以是事先预定的，也可以是在代码实践中逐步形成的，或者兼而有之。
PS：注意和项目经理的区别。
照理说，技术选型，考虑的应该是：
再次强调：三者不可兼得！
但实际上，大多数架构师，不过是出于个人偏好，^_^，因为凡是主流的技术，没一个是不安全、性能差、难以维护的！
Design pattern，热度逐年下降……
它起源于一本（应该算是经典的）书：《设计模式：可复用面向对象软件的基础》
看名字就知道，区别于架构设计，模式更微观，适用的领域更窄：几乎就只能面向对象。
由四个作者合著，被称之为GoF（Gang Of Four），书中总结出软件设计开发中常用的23中模式。
什么是模式？就是“套路”。比如：
Good Question！
从某种意义上说，设计模式和算法很类似，高端大气上档次，就是实际开发中用不到。
飞哥为什么不讲：
还想讲点什么？变化：很多设计模式，其实有一个假设/前提，业务逻辑以后要变
比如项目中使用了两种语言：一些模块用Java开发，一些模块用C#开发；现在我们想在这些模块中实现互相调用，即Java模块调用C#模块，可不可行？
在内存间通信是不可能的啦，但有一种办法：使用网络通信。比如Java模块暴露一个url，只要我们访问这个url，Java模块就能予以响应：这样的Java模块是不是就像服务器一样？它对外提供的，就是一种服务。
最早这种服务的使用只是为了解决不能/难以互相访问的模块之间的通信问题，但后来有人觉得好像所有模块都都这样部署也不错……？于是，SOA（Service-Oriented Architecture），面向服务架构，就被提出来了。
微服务就是微型服务，即：把大量的功能模块都主动的做成一个一个微型的服务。
好处：高度自治，野蛮生长。
想象一个项目小组，负责某个模块某个功能
但这样真的好吗？架构的本质就是纪律规范和约束，否则我干嘛要架构呢，大家一起嗨随便嗨不就OK了？
另外，微服务带来的另一个问题就是大量额外的桩和mock模块。比如我开发一个模块（UI都没有），这个模块怎么被触发启动（需要桩或者测试用例）？我还要调用其他的模块，但其他模块完全可能还未实现或者有问题，怎么办（需要mock）？对其他架构而已，单元测试是一种增益（可有可无），对微服务而言，单元测试是一种标配！
PS：微服务的问题其实类似于前后端分离，但更为严重……以我十年老码农的经验来看，还是可以让子弹再飞一会儿。
限制SOA及微服务的一个重要因素就是部署。
以前你的模块写好了，我代码（通过git/svn）拉下来就能跑，现在要用的模块，首先得部署起来！而部署，其实是很麻烦的，总是能在不经意间遇到各种稀奇古怪的问题……
所以docker应运而生：
Docker是一个虚拟环境容器，可以将你的开发环境、代码、配置文件等一并打包到这个容器中，并发布和应用到任意平台中。
docker就是一个类似于虚拟机、但更轻量级的软件，它可以把一台电脑的开发/部署环境很轻松的拷贝到另一台电脑，解决的问题就是：“在我的电脑上就能跑呀！”有了docker，我们都在docker环境里面跑。
PS：Java方向的同学学Linux的时候，可以直接用docker。
PostMan
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
