微服务初步理解

本文参考书籍

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

总结

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