使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化的方式部署。
关于微服务的其他内容，我的以下文章可以一一说明：
多微才算微服务？
其实微服务这个微不是以代码量或者开发时间来度量的，它传递的是一种开发思想，而不是固定的一个量。其思想表现如下：
服务的拆分和定义是一项挑战
服务的拆分是一门很深的学问，感兴趣可以详细了解TDD、DDD。拆分的太小，服务太细，服务之间的调用过于复杂，会造成不必要的性能损失，而且也要考虑团队的数量。服务太大，就会丧失微服务的优势。
分布式系统的一致性
微服务有自己的数据库。
沟通成本
微服务API的改变带来的沟通成本。
说到通讯呢，我们可能会想到，TCP/IP、HTTP、WEBSOCKET或者想到DUBBO、ZOOKEEPER等等，这么多的通讯方法，如何抉择？我们可以从两个方向来考虑通讯的问题。
服务发现的本质其实是服务调用者如何来发现服务提供者的ip和端口号。
传统服务一般就是通过Nginx进行负载均衡的转发，Nginx指定ip和端口号，一般是通过配置文件指定的，是写死的。配置文件的更新需要运维人员来手动操作。
如果是微服务的话，由于微服务数目众多，如果靠运维人员来手动操作的话，消耗人力也很大。所以微服务一般都是自动的服务发现，并且分为两类：
微服务启动的时候，会把自己的ip和端口号告诉注册中心，然后客户端通过查询注册信息得知微服务的ip端口号和列表，然后通过本地的负载均衡策略，来进行微服务的访问。
服务同样的把自己的ip和端口号注册到注册中心，但这客户端不会去访问注册中心了。客户端通过一个固定的ip访问到具有服务发现和负载均衡的服务，再由它将请求转发给后端的具体服务，并且将服务的应答转发给客户端。
微服务为了保证其高可用，一般会部署两个以上的相同服务，并且微服务很多，更新很频繁，这就需要服务编排。
流行的服务编排工具：
K8s以前介绍过很多了，也是这三者中处于霸主地位的工具，不多做介绍了。
微服务优势：
单体优势：
一般来说，产品初期会优先选用单体架构，业务复杂到一定程度后，微服务架构消耗的成本才会体现出优势。
我认为，其过程应该是满足 单体–>组件化–>微服务–>中台 的。在《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书中，也说明了这一点，并不需要一开始就微服务化，成本过高，每个阶段都需要一定时间的沉淀。
