微服务架构

最近在总结微服务方面的内容，看到了一篇来自笔名“PetterLiu”老师的文章，特别特别喜欢，转载如下，留作后续浏览。https://www.cnblogs.com/wintersun/p/6219259.html

首先，什么是软件架构？软件架构是一个多个组件构成的系统，包括前端UI, 后端应用服务器，数据库等存储和通讯层，它们彼此关联。软件架构的目标是解决利益相关者（stakeholder）的关注点。

康威定律

从某个角度来说，与其说微服务是一种技术架构，还不如说是一种企业组织架构。

Monolithic架构

Monolithic比较适合小项目，优点是：

开发简单直接，集中式管理, 基本不会重复开发。而分布式的设计难免需要引入重复代码

功能都在本地，没有分布式的管理开销和调用开销。

开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断

代码维护难：代码功能耦合在一起，新人不知道何从下手

部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉

扩展性不够：无法满足高并发情况下的业务需求

微服务架构

 微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的业务逻辑和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种松耦合、有一定的服务边界的面向服务架构。和面向对象设计一样，服务的设计应该是高内聚低耦合的：与一个业务相关的修改只在一个服务内部进行，并且一个服务的修改/部署不需要影响其他服务。服务边界的定义来自DDD领域驱动设计。服务边界的改变需要更大的变更成本。所以服务边界的划分需要投入精力认真对待。从设计原则上来说，服务的边界应该体现业务的边界。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面。

1. 服务粒度小：每个服务都是针对单一职责的业务能力的封装。

2. 独立部署和扩展：每个服务都能独立部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。同时微服务是无状态的（stateless），更加方便的实现可扩展性。且微服务能部署在中低配置的服务器上。

3. 独立开发和演化：技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

4. 独立团队和自治：团队对服务的整个生命周期负责（you build, you own it）；工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。完全可以由2-5人的小团队负责；且团队新成员容易上手。

除了以上四个特点，当我们谈论微服务的时候，我们还会谈到：

Resilient

A Microservice is designed for failure; it is fault tolerant and highly available

Responsive

A Microservice responds to requests in a reasonable amount of time

Intelligent

The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented

Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable

Microservices provide API’s for access by developers and administrators

Automated

The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

微服务架构 VS 单体架构

微服务 VS SOA

与传统的SOA架构相比，所谓“微服务”最大的特点可能就在于没有一个重量级的ESB。重量级的ESB有其历史原因。在2000年代业界刚开始采用SOA时，很多企业尽管把业务系统包装成了web服务，但IT团队的组织结构并没有发生改变，仍然是由一组人集中式地掌管整个业务流程——只不过系统集成的方式不再是直接的方法调用，而是服务编排（orchestration）。原本存在于集成代码中的复杂逻辑，现在被转移到了ESB中。而这个“ESB团队”成了IT交付的瓶颈：不论发布事件的服务还是消费事件的服务、或是编排逻辑本身的改变，与事件相关的变更都需要通过ESB团队。这个团队的backlog堆积起来，使得每个服务、每个应用都无法提供快速响应。

为什么采用微服务呢？

"让我们的系统尽可能快地响应变化" - Rebecca Parson 

上世纪90年代Kent Beck提出要拥抱变化，在同期出现了诸多轻量级开发方法（诸如 XP、Scrum）；2001年敏捷宣言诞生，之后又出现了精益、看板等新的管理方式。如果说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

微服务组件之间如何通信

通信方式分为同步和异步两种方式。同步调用简单，一致性强，但调用层次多的时候容易出问题，性能较差。同步调用通常通过Restful和RPC两种方式，目前我只用过Restful方式，它基于HTTP，实现简单，各个语言都能支持，对客户端没有特殊要求，只要封装了HTTP的SDK就能调用。“传说”RPC的优点包括传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。异步调用（消息）在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

微服务缺点

1. 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).

2. 分布式系统可能复杂难以管理。

3. 因为分布部署跟踪问题难。

需要考虑的问题

单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。

单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。

单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。

多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。

微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。

还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。