从GO与Docker联系到分布式和微服务
在学习go的过程中，发现github上的go项目基本都会使用docker和k8s。
随便clone一个项目都会有dockerfile文件。有了它的环境使用docker快速部署还是很方便的。
但是若不使用docker，直接本地npm i之后，前端甚至都跑不起来，属实有些郁闷的，有的必须要过docker这一层，不然运行不了(可能是linux的环境，我是win10)。
于是就逐渐了解了一些docker相关的内容，最后又了解了一些K8s相关的，一个容器技术，一个容器管理。逐渐感受到Go和它们俩是不可分割的或者是相互依赖的。
应用场景
go语言主要应用于后端，并发编程特性，加上模块化，对现代web开发逐渐功能组件化有实用的应用场景。
常用来开发一些网络中间件，或者做API服务，或者干后端C++的那些事，或者云平台(尚且不明白云原生、云计算等具体的应用内容)。
docker热门
一般作为中间件都需要使用docker，封装为一个个容器，互相间通过api调用，最后又通过K8s管理这些容器，形成一个整体。
docker的热门我认为主要因为现代web开发的两个趋势，分布式和微服务，各个功能模块的解耦合，但是最终仍然要协同工作，各个组件的开发环境各异，需要一个上层的隔离来使其之间能够充分协作。
微服务
web开发普遍使用docker一是因为微服务。后端的各种服务或中间件开发环境各异，最后又部署到一个环境中作为一个总后台。容器技术用隔离解决了环境问题。
可以说前后端分离就是一种微服务的雏形，只不过现代需要把后端的功能再分，前端一般来说分不了啥了。
微服务不见得就好，开发容易维护难，组件越多，维护成本越大。而且说是模块化，上游组件出问题了，下游功能不可能不受影响。
单体服务的优势仍然明显，整体容易维护，开发遇到的问题也肯定比微服务少。我认为一般项目前期不需要考虑微服务，功能逻辑并不复杂的前提下，单体服务仍然是优解，等各个功能模块扩充了，再使其组件化向微服务发展也不迟。
分布式
二是因为分布式架构。相同的服务需要部署到多个服务器上，不同服务器环境也不同，仍然需要容器技术支持。同时也可以让一个功能的中间件无视环境多处复用。
显然，分布式会加大服务器物理资源的消耗，需要更多的服务器成本，这可能需要更多的中间件支持。
想让专业的组件干专业的功能，但实际上越分离成本越大，而且互相之间其实不能完全分离，虽然提供了api接口作为通信，但实际上功能变动带来的影响，同一团队之间可能熟悉怎么解决，而分开开发可能就会埋有隐患。
