优点：降低耦合、增加并发、方便部署，
    缺点：系统复杂度变高了，难以维护，成本变高了

    微服务是什么？
    1、微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，以提供更大的吞吐量。
    2、每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP+协议的RESTfulAPI+）；
    3、每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境；
    4、微服务应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务需求，选择合适的语言、工具对其进行构建。

    微服务的核心是服务治理，而服务治理的关键是服务划分。故微服务架构的本质就是对码农的分化和治理。微服务对于互联网产业的意义就像流水线标准化生产模式对于制造业一样具有革命性。福特汽车发明流水线标准化生产模式改变了制造业工程师和工人的治理模式及责任划分，使组织大规模成批量工业生产更为简单。而微服务架构也可以使大型互联网公司更容易建设面对海量用户的互联网服务系统。因此微服务架构是让互联网产业模式逐渐靠向传统制造业的标志。

    在早期互联网发展中，一般采用单体开发模式。例如开发一个在线购物商城，单体开发模式最多把整个项目分为前端后端两部分(前后分离)，后端开发则是由一批程序员从数据库设计开始再到业务层如用户注册，店铺管理，商品管理，商品展示，订单支付，物流管理，评价系统等模块顺序延伸开发，最终所有模块开发完成的代码合并在一起统一编译部署上线。在单体开发中大部分程序员都可以全面理解整个业务构成并随着开发时间轴推进参与到各个模块的开发。这就如同早期汽车厂的生产一般是工人们先造发动机再造变速器后车身最后再组装的模式一样，所有工人工程师贯穿整个生产流程。
    单台服务器(单体程序)一旦有一处错误，经常整个网站就得停止运转，其次随着互联网发展的深入和业务量的增长，单台服务器和单个程序已很难响应巨大的访问流量，这时集群模式就登上了舞台。不过集群模式也相对容易，简单来说就是把一个单体程序同时部署在多台服务器产生一堆节点，然后再用诸如Nginx这类代理工具以一定的规则(例如对IP地址哈希)把请求分散到不同的节点，类似的还有数据库读写分离主从互备等等，总而言之就是把单体时代的单台单个镜像复制到多台，程序开发需要顺序进行无法分割的本质并没有改变。用汽车制造来举例子就是多开几家工厂，但每家工厂还是先造发动机再造变速器后造车身最后再组装得贯穿式生产模式。
    随着互联网产业的发展，一些公司的业务已经非常庞大，如果还是单体开发批量部署的模式显然很难进行有效管理。这时就有一些企业从业务层面分割原有系统，比如对电商平台可以把以前完整统一的系统分割为商品展示，用户管理和支付平台三大部分。每个部分单独开发独立部署，他们之间使用轻量的API调用进行数据交互。这样每个部分都可以由不同的团队互不干扰的独立开发，只要彼此遵守事先约定的规则。而不同的业务所耗费的资源也有差异，服务拆分之后可以根据不同业务的负载分别调整每一部分的服务器投入。这就是微服务架构的雏形。如同汽车工厂把发动机，变速器和车身交给不同工厂同时进行生产研发，然后再统一调度总装生产。
    在把完整系统根据业务拆分为几大独立系统的基础上，再进一步对各个业务进行更细粒度的拆分，比如把商品展示再分为商品图片上传，图片审核，图片处理，评价查看，评价管理，评价删除，购物车查看，购物车添加，购物车清零等等子服务就是微服务的实践。每一个服务都由独立的团队开发维护就像汽车工业进一步把发动机，车身，车轴三大工厂拆分为曲轴，活塞，缸体，轴承，轮毂，车架，车门，玻璃等等小工厂，各个工厂负责一项零部件的研发生产，然后再通过逐级流水线装配形成汽车。
    因此我们可以看出互联网的微服务架构和汽车工业的标准化流水线生产非常相似，所以微服务对于互联网工程师工作形式的改变也会如同汽车工程师一样越来越细分化。150年前的汽车工程师可能需要了解整车，100年前的汽车工程师需要掌握发动机或变速器里一个大部件，而今天的汽车工程师则可能只会了解曲轴或活塞这样的单一部件。20年前面向业务编程的程序员基本全业务都要了解，而今天的面向业务程序员则逐渐开始分化为例如支付领域，直播平台领域，电商领域等等。
    汽车产业中每个零件通常都有多个供应商，多个供应商也可能会拥有数条生产线，每个供应商或生产线虽然生产同样规格标准的零件但也可以通过不同的设备不同的工艺达成。微服务架构也类似，每个微服务实例可以同时多个节点部署，比如电商平台的评价系统可以同时部署在多台服务器上，而每个服务器上又部署多个实例。这样一两台服务器出现宕机不会影响整个电商平台集团业务的运转。而每个服务实例也可以用不同语言不同框架编写只要他们对外暴露同样的接口。
    同样的服务实例可以由不同的语言不同的框架实现并同时上线就意味着可以在整个系统运行中对服务进行无需停机的热升级，那也意味着系统升级的代价几乎可以忽略不计，而且同一个服务也可以由多个技术团队分别实现。这样新手程序员无需了解整个系统的架构和体系就可以快速参与到系统开发升级中，他们开发的服务实例也可以以渐进形式取代旧团队开发的既有实例，一旦有问题可以迅速回退补救。完全可以等新团队的实例在使用中经受住了测试再把新团队的实例负载比例提高到50%以上，然后把旧团队的薪资过高老人优化掉，在维持平稳的前提下为公司降低薪资支出优化技术人员结构。微服务架构把整业务解耦和拆分其实极大降低了大型互联网系统的开发和管理难度。每一个服务实例都可以通过多个团队的竞争选取最优，也方便进行外包，这是大型互联网公司非常希望看到的。
    微服务架构概念就是制造业的零件标准化渗透到互联网产业，当越来越多的软件工程师只能把工作范围缩小到部分服务后，这意味着他们的竞争指标细化，码农的互换性和可替代性也会快速提高，他们的流动性对整个系统的稳定性冲击也会变小，这意味着面向业务编程的互联网工程师薪资议价权会同制造业工程师一样越来越弱。
    零件标准化也会带来通用化，比如很多汽车厂都会采购同一个工厂的同一种零件，单个零件产量越大成本越低技术越成熟。那各个互联网企业的一些通用服务是不是也会在未来被整合到一起，重复造轮子的企业会越来越少？现在各个互联网巨头都在搞云计算，他们的云平台也提供了大量符合微服务概念的服务计量出售，比如现在可以在腾讯云阿里云买到短信验证，对象存储，视频点播直播等大量成熟基础服务。在微服务架构下，建一个B站这样的视频网站就可以找几个外包团队融合云平台的接口做好各个服务实例打成容器镜像，然后交给云平台自动编排弹性伸缩服务。所以目前重新建一个B站的壁垒不是技术而是市场和资本。
    总结: 微服务架构之于大型互联网公司就像流水线模式对于富士康这样的大型电子厂。每个服务就是一个工位，大部分码农只能在长期在同一个工位上干一些随时可以被取代也毫无技术含量的活。而越来越多常用业务功能也会以各种形式被互联网巨头做到白菜价以标准品出售。参照非标制造是制造业待遇相对较好的情况，那么游戏这种实时性要求高无法采用微服务架构的非标开发可能也会相对更好。