微服务初步理解

本文参考书籍

https://github.com/oopsguy/microservices-from-design-to-deployment-chinese

 

微服务简介

单体应用

在项目开发启动阶段，比如开发一个电商系统，该系统包括了订单模块、商品搜索模块、用户模块和后台等系统，启动阶段虽然按照业务逻辑分模块开发，但是最终成功上线运行的是一个单体应用，在项目开发的初期，单应用的架构有助于快速更改业务流程，快速迭代，当项目发展到一定时期后，一个庞大、复杂的单体，对于新的功能的开发可能就是陷入了很大的困境，无论是修复线上小的问题还是新需求的开发都设计到整个项目的重新部署和测试，并且降低了开发的效率。

当项目发展到一定阶段后，不同模块存在资源需求的冲突，单体应用可能难以扩展；当单体应用在线上实际运行过程中，任何一个模块出现一个bug，都可能会导致整个单体应用不可用。当需要对项目中开发的某个模块进行灰度发布的时候，单体应用往往也不能满足很好的扩展性。那么如何进行改进呢？

微服务

通过将应用程序分解成一套比较小的互联服务，即微服务架构模式。一个服务通常实现了一组不同的特性或功能，例如用户模块等。每一个微服务都是一个迷你应用，都包括了自己实现的业务逻辑，暴露了对外服务的接口，服务可单独部署与开发。

应用程序的每个功能区域都由相应的微服务实现，每个后端服务暴露相关接口，服务之间可以使用异步或基于消息的通信，一些API也暴露给移动端应用，但是应用不能直接访问后端服务，它们之间的通信都由一个API网关的中介负责，API网关负责负载均衡、缓存、访问控制、API计量和监控。微服务架构模式影响到了应用程序与数据局之间的关系，与其他共享单个数据库模式服务有所不同，其每一个服务都由自己的数据库模式，这样就可以实现松耦合的结构，并且服务可根据自身的需求选择不同的数据库，以达到最佳的适用场景。每个服务也可以选用不同的技术栈来实现不同场景的业务。

微服务优缺点

优点

1.解决了复杂的问题，将庞大的单体应用分解成一套服务，虽然功能数量不变，但是应用程序已经被分解成可管理的服务，每个服务都有一个明确定义的API，如RPC或消息驱动，每个服务能更快地开发并更容易理解与维护。

2.每个服务都可以选用不同的技术栈，由不同的团队开发维护。

3.每个服务都可以独立部署。

4.微服务使得每个服务都能够独立扩展。

缺点

1.由于微服务是一个分布式系统，其使得整体项目变得复杂，开发者需要选择和实现基于消息或者rpc的进程间通信机制，此外，由于目标请求可能延迟或不可用，还需要额外的处理机制保证通信。

2.微服务面临着分区数据库问题，在基于微服务的应用程序中，需要更新不同服务的数据库，一般不会选择分布式事务，不仅因为CAP定理，也是因为如果使用了NoSql数据库和消息代理，就没有很好的支持，最后使用最终一致性方法，这对开发人员来说更具挑战性。

3.微服务的测试工作相对复杂，一个微服务的测试需要启动该服务所依赖的所有服务，增大了测试的难度。

4.微服务的部署工作也相对复杂，一个单体应用可以很容易地部署到基于传统负载均衡器的一组服务器上，相比之下，微服务应用程序通常由大量的服务这次，每个服务都可以有多个运行时实例，这对服务的发现机制，服务的部署监控和扩展都提出了更高的要求。

总结

构建微服务本质上需要考虑的方向很多，需要根据当前项目的业务紧密相关联，单体应用适用于简单、轻量级的应用程序，如果应用发展到一定规模，微服务架构虽然复杂、维护大，但是保证了业务的灵活性和扩展性。如何选择需要实际业务进行选择。