认识微服务

维基百科的定义

  微服务的概念最早是在2014年由Martin Fowler和James Lewis共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通讯。

为什么服务化

  与微服务相对应的是单体应用¹。随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。大概会有以下几个方面的问题。

1. 部署效率低下：当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要10分钟以上。
2. 团队协作开发成本高：早期开发团队只有两三人的时候，协作修改代码，尚可控。但当人数增加时，测试阶段只要有一块功能出现问题，就需要重新编译打包部署，然后重新预览测试，所有相关的开发人员又不得不参与其中，效率低下，开发成本极高。
3. 系统高可用性差：因为所有功能开发最后都部署到同一个WAR包里，运行在同一个Tomcat进程中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个WAR包中部署的功能。
4. 线上发布变慢：一旦代码膨胀，服务启动的时间就会变长，有些甚至超过10分钟以上，如果机器规模超过100台以上，假设每次发布的步长为10%，单次发布需要就需要100分钟之久。

  为了解决以上这些问题，服务化的思想也就应运而生。
  服务化的思想就是将单机应用中的本地方法调用改造为通过RPC接口来进行远程方法调用。以改造调用方式的方法将业务从单体应用中拆分出来，独立成一个服务部署。

什么是微服务

  微服务是服务化思想的进一步演化。与服务化对比微服务有以下几个特点：

1. 服务拆分粒度更细：微服务可以说是更细维度的服务化，小到一个子模块，只要该模块以来的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
2. 服务独立部署：每个微服务都严格遵循独立打包部署的准则，互不影响。
3. 服务独立维护：每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
4. 服务治理能力要求高：因为拆分为微服务之后，服务的数量变多，因此需要有同意的服务治理平台，来对各个服务进行管理。

微服务引入的架构复杂度

  引入微服务后，必然在项目上也会引入新的复杂度。也就是必定会遇到如下几个问题：

1. 服务如何定义：也就是如何让方法对外提供服务，答案是使用接口，服务之间的调用都通过接口描述来约定，约定内容包括接口名称、接口参数以及接口返回值。
2. 服务的发布和订阅：这里需要解决的问题有两个，一个是服务者该如何对外暴露自己的地址，第二个是服务调用者该如何查询所需要调用的服务地址。答案就是引入一个类似登记处的地方，让服务提供者将地址注册到登记处，让服务调用者需要调用时，来服务中心查询。这里的登记处就是注册中心。
3. 服务如何监控：需要有一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能。
4. 服务如何治理：拆分为微服务架构后，服务的数量变多了，以来关系也变复杂了。如果一个服务的性能有问题，依赖的服务都势必会收到影响。这时就需要设定一个调用性能阈值，如果一段时间内超过这个值，那么依赖服务的调用可以直接返回，这就是熔断。
5. 故障如何定位：如果服务调用时出现问题，需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。

Cloud-Platform是如何解决微服务的复杂性问题

1. 服务如何定义：使用HTTP的方式来定义服务
2. 服务的发布和订阅：使用nacos来做为服务中心来发布和订阅服务
3. 服务如何监控：使用spring boot admin来监控各个独立service的运行状态；利用Hystrix Dashboard来实时查看接口的运行状态和调用频率。
4. 服务如何治理：使用Hystrix做为熔断器来进行服务治理
5. 故障如何定位：不支持故障定位

---

1. 早些时候，各大互联网公司的应用技术栈大致分为LAMP(Linux+Apache+MySQL+PHP)和MVC(Spring+iBatis/Hibernate+Tomcat)两大流派。无论是LAMP还是MVC，都是为单体应用设计的，其优点是学习成本低，开发上手快，测试、部署、运维都比较方便甚至一个人就可以完成一个网站的开发与部署。 ↩︎