微服务架构基础知识

微服务架构简介
微服务是架构层的一个概念，通过分解（业务单元），将项目拆解出 n 个单元，
互相没有强依赖关系（解耦），自我准备需要的依赖条件，进而达到可以独立运
行，不再受环境与地点上的限制。

微服务的由来
微服务最早由 Martin Fowler 与 James Lewis 于 2014 年共同提出，微服务架构风
格是一种使用一套小服务来开发单个应用的一种方式，每个服务运行在自己的
进程中，并使用轻量级机制通信，通常是 HTTP API，这些服务基于业务能力构
建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实
现，以及不同数据存储技术，并保持最低限度的集中式管理。

传统的应用模式

我们在以往的传统应用模式下，大致是所有的功能都集成在同一个应用中，这
种模式一般被称为单体式开发，即所有的功能打包在一个 war 包内，然后部署
在 jee 中，这里面包含了所有的业务逻辑，触发器，大部分的还包含了 ui，如下
图：

这样的模式下暴露出了他致命的缺点：
　　• 代码管理比较难，因为大家都在同一个工程下，会经常的发生冲突
　　• 新人不太容易上手，因为耦合性太高，调查一个问题时往往会牵扯更多的
　　  功能
　　• 打包危险度大，往往只是提交很小一部分的修改却需要全量打包
　　• 运维危险度大，可能只是某一个功能崩溃了就会导致整个系统瘫痪
　　• 不容易扩展，如果只是一个功能的请求量突增，不容易扩展
　　• 部署要求较高，这样的应用往往需要高配置的主机来承载

微服务的应用模式
我们在做架构设计的时候，常常需要遵守三个标准（敏捷性、用户体验、成
本），基于微服务的架构设计目的就是有效的拆分应用，每个应用单独管理，进
而实现敏捷开发和部署，如下图：

由一些独立的应用组合成一个软件系统，每个服务独立运行，跑在自己的微环
境中，每个服务独立开发可以按照业务单元进行拆分，实现了跨组织夸地域协
同的问题，多个服务采用分布式进行管理，且具有强隔离性。

微服务架构
在微服务架构中，除了每个业务单元的服务外，就是那些服务治理组件了，比
如：服务中心、服务消费、负载均衡、断路器、智能路由、配置管理等，这些
个组件互相配合再加上业务的各个微服务，共同组建了一个微服务系统，一个
简单的微服务系统如下：

用户通过客户端发起请求，nginx 负载到某个 zuul 上然后转发到相应的微服务
上，微服务间通过 rpc 或者 mq 进行通信，通过配置服务获取配置数据，最终将
整合后的结果返回给用户。

微服务的优缺点
微服务架构之所以流行起来，与他的这些优点密不可分，比如：
　　1. 他将巨大的单体式应用分解出多个服务，解决了复杂性的问题，在总功能
　　   不变的情况下，系统被分解成多个可管理的服务，每个服务都用 rpc/mq 来驱动
          和定义清晰的 api 边界，为很难实现的功能提供了模块化的解决方案，并且更容
          易开发和维护。
　　2. 在这样的架构模式下，可以实现每个服务可由不同的团队来开发，从而放
　　　 宽了技术选型，只需提供标准的 restapi 即可，在这种自由模式的开发背景下，
           开发者可以选择较新的技术，由于每个服务的功能很小，所以开发的难度也很
          低，即使出现了代码重写的问题难度也不是很大。
　　3. 由于微服务采用的是独立部署，开发者在部署的时候不用考虑其他的服务
          对自己的影响，这种改变加快了部署速度并减少了部署风险，微服务架构使
          ci/cd 成为可能。

但是微服务也存在一些不足，比如：

　　1. 微服务采用的分布式系统，故而会产生固有的复杂性，开发者需要在 rpc
           等消息传递之间完成进程间的通讯，更或者需要用代码来解决消息传递过慢或
           异常的情况。
　　2. 来源于数据库事务的分布，以至于我们不能达到强一致性，只能的选择最
           终一致性
　　3. 当我们对某个服务的某个 api 进行测试的时候，需要保证这个服务所依赖
           的其他服务都是正常开启的状态，这给测试带来了复杂性的问题。

 

最后，一般提到微服务都离不开 DevOps 和 Docker，理解微服务架构是核心，
devops 和 docker 则是工具，是手段。