目录
1 生活中的微服务
换季了，天气变凉，不小心得了感冒，去社区诊所看病，诊所中的医生负责接待、问诊、检查、开药、打针一条龙服务。一个医生搞定所有的工作。这种模式就是单体架构。
但是如果得了大病，小诊所是无法处理的 ，需要到大型的三甲医院看病，我们会发现三甲医院里有人负责挂号，有人负责问诊，有人负责检查，有人负责打针，有人负责抓药，所有的模块都是分开的，我们需要带上医保卡先去找医生，医生给我们开各种条，我们带上条到什么地方把纸条交给窗口对应的人就会做相关的工作。这种模式就使用了微服务的思想。
三甲医院把工作拆分的很细交给不同的人来处理，而不是把所有的工作都让医生来完成。这样做的好处是每个人都做自己擅长的事情，比如医生只负责问诊、开药方，这样大大提升了资源的利用率，其中一个环节中的一个人出现问题，不影响整体的进程，比如抓药的窗口有很多，一个窗口出现故障我们可以到其他的窗口。我们设计的系统，刚开始的时候业务逻辑比较简单，并发也没有那么高，一个系统可以负责所有的工作，但是随着业务的快速增长，业务逻辑的复杂，一个系统处理所有的工作性能就会出现瓶颈，这时候可以把系统拆分成多个，每个子系统处理不同的逻辑，这就是微服务的核心思想。
2 服务架构的发展
单体架构
社区诊所所有的工作都有医生一个人来完成，这就是单体架构，单体架构就是把所有的功能模块都集中在一个系统中，所有的开发人员都在这个系统中实现自己的模块。假设我们把看病流程当做一个项目，架构图如下所示：
集群
随着社区入住率的提升，病人的数量也大幅增加，社区医院一个医生服务不了所有的病人，于是又招个一个医生。这就是集群的概念，如下图所示：
从图中可以看到，医生A和医生B做的事情是完全一样的，招入医生B是为了给医生A减压。我们通过增加应用服务器的方式来将应用服务器集群化，这样就可以将用户请求分流到各个服务器中，从而达到继续提升系统负载能力的目的。
微服务
把功能查分到细粒度，把每一个模块或者功能拆分钟紧凑的小服务，部署在不同的服务器上，即把一个人干的事情分给多个人来干，社区诊所的医生需要接待病人，问诊，检查，开药等，但是接待病人跟医学知识毫无关系，那就可以找个专门接待的人负责，同样的仪器检查和抓药都找专业的人来做，这样各司其职，各尽其责既能把资源充分利用起来，有大大提升了看病的效率，架构图如下所示：
微服务分布式非常相似，区别就在于，分布式偏重于减轻压力，把服务发布在不同的机器上，微服务偏重于分散能力，拆分出的服务可以发布在同一台机器上。简单的来说微服务是一种架构设计方式，分布式是系统部署方式，两者的概念不同。
3 微服务的优缺点
微服务的优点
1、独立部署、扩展性强：微服务的每个小服务独立部署，如果某一个服务出现性能问题可以灵活扩容；
2、分工明确，提升资源利用率：每个服务都提供单独的业务能力，按照业务能力划分小组，每个小组6-9个人，开发并行来做，能够把资源重复利用起来；
3、去中心化治理：微服务中某个模块出现问题，不影响其他模块的正常运行；
4、支持跨语言：每个微服务提供http或者restful接口，支持跨语言开发。
面临的挑战
1、需要对业务充分了解：对业务充分理解才能拆分微服务；
2、微服务过多，服务治理成本高，不利于运维团队系统维护，需要开发人员自己维护。
