微服务是什么？
每个人都有自己的理解；对于从事过大型系统开发的人来说，理解他 更有体会。
2010的时候 我们参与的国家电网95598的系统设计与开发，最开始就是 单体应用；
随着业务的深入理解，安全部署 （内外网隔离）的要求；
单体应用开始分拆成 内网应用服务，内网数据调度中转服务，外网web应用；数据调度中转服务；
那个时候 用的是xfire 进行服务调用；数据中转通过轮询隔离装置 放在 memcached；
每个来调用的人 都给他一个 号(挂号)，然后提供一个 获取结果的接口，拿号去轮询获取；
因为 部署的安全要求分拆系统， 这还不够，随着业务的发展，需要做支持 多渠道；
我们支持了 短信服务，app服务，wap网站服务，内部第三方接口服务；
于是又 按照 类型进行 按端拆分，统一后端的服务；
前端通过nginx来 做静态缓存，中间服务集群 通过nginx来做负载分发；通过memcached集群来做 数据缓存；
再后来 用户达到上千万级别的时候，用户服务也进行了拆分，还进行了分库；
总结一下：
当时主要方式是：模块化(分拆为子系统)，统一公共服务层，集群部署，拆库。
那么现在 微服务的理念是什么？是全新的么？我 认为不是；
只不过 之前 互联网的大系统少，讨论的不够普遍，现在 接触的人 越来越多了，就会有人去 改进他，优化那些传统的方式方法；
我理解的微服务特点：
按照业务 分拆服务，粒度到功能级别；啊哦，一堆 一堆的 war包或者 jar包；
每个服务可以拥有独立的数据库，可想而知 后面 有一堆 一堆的数据库；
各服务之间 通过接口 或者 MQ进行交互；
当然 每个服务 也是集群部署的；
按照业务拆分的 好处是 灰度发布；一次 升级一次服务，风险控制到最低；
OK 这么多 服务 怎么管理？
于是需要 服务治理； 服务注册 服务发现 服务的监控 负载分发 健康检查(nginx 干的那些事) 接口数据缓存 还有接口权限的管理；
最后 这么一大堆 包 部署 运维 是个麻烦事吧，所以 还需要 自动化运维部署 这些配套设施。
还有一个好处就是 重构 方便，公司中人员流动是很频繁正常的，不要指望 程序员都会按照规范 写代码，坑都是一堆堆的。
单体项目中 模块之前的依赖 藕断丝连 错综复杂，改了都头疼。
而微服务的理念 可以 解决这个问题，因为足够小，所以即使写的比较糟糕，读懂业务后 就直接 干掉，重写，换个技术框架 甚至语言 都是可以的；
技术上：spring项目换成了springboot，外部 tomcat部署 换成 自带容器jar包启动(启动真心快)，rest服务就不说了 之前的xfire+xml 换成springmvc+json
追究 简洁，独立，隔离，高效；
缺点当然 也是很多，我就不啰嗦了，一会看 大神的分析：
1090
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
