先来说一下概念，微服务就是一群协同工作且小而自治的服务。在微服务中存在下面这些特征：
什么是内聚性呢，就是将因相同原因而改变的东西聚在一起，因不同原因而改变的东西分离开来，这么一种隔离形态。
微服务这个名词听起来就有小的特点，那么小到什么程度才能叫做小呢，其实这个小的把控是微服务里面很难把控的一个东西。其实，我们只要能够保证在两周左右能够对整个服务器进行重构甚至更换其技术栈，就能称之为小。
服务之间独立运行，相互之间不影响，不会因为某一个服务的不可用而导致整个系统的瘫痪，重新部署某一个微服务对其他服务器不会产生仍和影响，其实这个也是微服务架构设计过程中的一个黄金法则。
服务之间协同工作的方式是通过网络通信方式来进行数据交换等操作。
说完什么是微服务，那么我们就来讨论一下微服务有哪些优点呗，为啥现在互联网公司普遍都采用微服务的架构。
- 微服务相互之间的耦合度很低，且服务之间的调用走的是网络通信，对服务的具体实现方式并没有强制要求，所以我们可以在不同的服务中采用更适合这个服务的技术栈。
- 小，我们可以在不是很重要的服务上引用新的技术而不必担心新的技术会对整个系统产生破坏性的影响。而且就算出现问题，上面也说了微服务，小嘛，我们完全可以在两周内完成它的重构甚至是重写。
因为内聚性高，分工明确，所以当系统出现问题的时候，我们很容易定位出是哪个服务出现了问题，并很快修复。
- 很容易进行扩展，当某个微服务所在的服务器不够用的时候，我们只需要为该服务添加机器即可，而不需要给整个系统都增加服务器配置。
- 灵活，我们可以将一些并不要求性能或者很小的服务放在配置较差的服务器上运行，动态灵活的分配服务器资源。甚至有时候可以通过这种方式来节省研发成本。
修改了哪个服务就发布哪个服务，不需要发布整个系统，在操作和风险上都很棒。
通常一个微服务只需要几个人的小团队来维护就好，我们大家应该也知道，通常情况下小团队的工作效率会比大团队高上不少。
实际上就是Java中的jar包吧，这个还是会限制我们的技术选型，因为一般共享库的引入基本上都是要求同种语言退其次也要求同一平台下的技术环境。还有一个问题就是共享库的版本维护很困难，如果一个库在多个项目中被引用，那么我们更新起来会很麻烦。
主流的Java8还不支持这一点。