技术每年都会有新的概念产生，这也是说为什么it行业需要终生学习的原因。不过如果不出现大的技术变革，计算机的原理没变，那么学习各种技术相对还是比较容易，大多还是从设计理念上的改进。即使是这样，每年也都有很多新名词出现，我们不可能每一种都去学习，但是该了解还是需要去了解一下。至于用不用，还是看业务需要。
讲微服务之前，先了解一下什么是服务化
服务化（SOA）是一种构建分布式应用的方法，本质上是实现代码模块到服务的转变，以方便同样的代码块在分布式环境中的重用。
便捷性：屏蔽底层复杂度，调用方想函数一样调用，不用关心内部实现，可以提升代码效率和协作效率
复用性，防止代码拷贝，服务内部更新调用方不用做更改，做到了调用服务方和服务方的代码解耦
专注性，服务化以后，和其他的服务或者调用方不再有耦合关系，服务本身代码容易更加健壮（比如做数据服务增，可以很好地内部控制缓存和sql质量）
性能提升：不同粒度的服务化，可以不同程度上增加系统的伸缩性。帮助系统进行拆分，比如业务垂直拆分，映射到数据增就是分库
这里我自己都没搞懂，我暂时的理解是，微服务就是一定细粒度上的服务化，具体多细，对不起不知道。但是我只需要知道他是服务化，就必然也有服务化的优点和缺点。
那一定是因为他的优点了，上面那些优点都是。尤其是Google的Jeff Dean的观点：让Google具备了千人并行协作开发的能力。这正好和我最近管理的时候想起的怎么提高多人协作效率的问题不谋而合。
如果项目开发初期，团队比较小，一个项目所有代码都写在一起三五个人每个人负责一部分，偶尔发生git冲突了解决一下，也没有什么问题，大家整体效率还是很高的。但是当项目体量逐渐大了以后，团队协作各种问题都会浮出水面。我简单举例
如果商品数据层要做缓存，怎么做？如果不做服务化，那么一个项目所涉及到的代码都要做缓存处理，比如前台的接口，后台的接口，定时脚本的接口等。都要在orm系统或者dao文件中写一遍缓存功能的增删改查，如果谁那边代码写的不好，缓存加了没有删除，删除了没有加入，都会出现数据问题，每个项目组都要进行排查。而服务化以后，只有服务层做一次就可以，出了问题如果定位为服务层问题，也只需要这一组去排渣即可。 2. 如果项目组想要增加人数来增加开发效率，怎么办
传统的如果项目没有拆分服务化的时候，往项目中增加人数，按照人月神话的理论来说，不仅不会增加效率，还有可能带来更多问题。因为这里面涉及到沟通成本和了解成本，还有可能互相影响。而微服务就是把代码进行细分成某个粒度，正好让大家各司其职，都做自己的事情，只是最终彼此调用，但是又不用关心彼此是怎么实现代码的。这样从整体上来说就可以达到各团队成员职责解耦，降低了互相之间干扰和沟通的成本。
其实在三年前上一个公司的时候，和一个同事谈论这个系统拆分的时候，自己就已经有类似的想法，不过那时候我还只是其中一个项目的技术经理，并没有对此进行实际操作。
根据上面的理解，我们在考虑要不要用微服务的时候，首先就要知道，如果你目前用不到微服务的任何优点，就不要尝试去使用微服务。不要为了使用新技术而使用新技术，技术都是用来解决问题的。
所谓的解耦，都是因为真的到了需要解耦的时候。对应到技术使用也是一样，不使用这个技术，已经开始造成了明显的问题，那么就是你该寻求新解决方式的时候了。
以前创业的时候和朋友聊天他说了一句话：当你自己就可以搞定的时候，就自己搞定，因为自己一个人毫无牵挂跑的最快。当你发现你自己解决不了所有问题，需要引入其他合伙人的时候，尽量选择哪种和你最匹配的，内耗最少的。当时深以为然。映射到技术上也一样。在对的时候选择对的技术就好，选择了太超出当前体量的技术，徒然增加了复杂性反而可能降低效率。
