微服务是一些协同工作的小而自治的服务。
1.1、服务小、专注做好一件事
微服务需要根据“内聚性”与“单一性原则”把相关代码放在一起。（单一性原则：把因相同原因而改变的东西聚合在一起，把因不同原因而改变的东西分离开来）
微服务要足够小，不要过小。如果你不觉得代码库过大，可能它就足够小了。
服务越小的优点：带来更好的独立性。
服务越小的确定：管理大量服务比较复杂。
1.2、自治性
一个微服务就是一个独立的实体；
每个微服务可以独立的进行修改，一方服务的部署不应该引起该服务消费者方的变动；
一个微服务可以独立的部署在PAAS（platform as a service）；
需要避免把多个微服务部署在同一个服务器上；
服务之间通过网络调用进行通信，加强服务之间的隔离性，避免紧耦合；
服务间暴露的API接口的实现技术应该避免与消费者耦合，选择与具体技术不相关的API实现方式，以保证技术的选择不被限制。
2.1、微服务好处
技术异构性：可以在不同微服务使用不同技术，保证各个微服务选择最合适的实现方式；
弹性：系统中一个组件不可用后，不会影响其他组件的使用，微服务是把单个服务拆分成多个服务，同时各个微服务部署在不同机器上。
扩展：庞大的单块服务只能作为一个整体进行扩展，其中一个产生性能问题，也需要对整个服务进行扩展。而微服务则可以单独的修改由性能问题的微服务，方便扩展；
简化部署：在单块服务中即使一行代码修改了，也需要部署整个服务，但是微服务可以避免这种情况，只部署修改的微服务即可；
与组织结构相匹配：微服务可以与组织结构相匹配，保证小团队更加高效，避免出现过大的代码块；
可组织性：每个微服务都可以被多个不同消费者调用，从而达到了可重用、可组合的目的。
对可替代性的优化：使用微服务时，可以单独的优化某一个服务，所以重写或者移除一个或者多个微服务的阻碍更小；
3、面向服务的架构
SOA是一种设计方法，其中包括多个微服务，但是SOA并没有定义通讯协议如何选择，第三方中间件如何选择、服务粒度如何确定等问题。
4、其他分解技术
基于微服务的架构有两个优势：
它具有足够小的粒度；
它能在解决问题上给与更多的选择；
共享库：不同团队和服务可以通过库的形式共享功能；（缺点：库必须使用同一种语言，每次更新库都需要重新部署整个进程）
模块：除了把系统分为不同的服务之外，可以通过在一个进程内部使用模块进行划分。