鲜驰达项目之第三次重构--微服务之微服务架构阐述

前言：记得上次XCD项目第二次重构的时候，是以模块为主，将每一个业务模块切分出来，对于共通的代码实现或者SQL的编写没有实现通过接口调用，而是通过Spring AOP根据Package来定义数据源。当初的设想是，可以将每一个模块进行独立部署，但是因为没有去调研自动发布等工具，导致发布需要手动改动Pom文件，而放弃模块独立发布的初衷。这样就导致第二次重构的设想有一些失败。只是单一的将代码切分开。

为什么要进行微服务重构。

在阐述为什么要用进行为服务重构的时候，需要介绍什么是为服务，为什么会选择微服务。

什么是微服务：其实对于未服务的定义，也没有什么唯一的标准定义，就像NoSQL一样，我们一直在讨论，我们也知道大致的NoSQL的含义，也可以根据不同的场景使用NoSQL，但是如果让我们给NoSQL一个准确的定义，其实很难。其实微服务也想NoSQL一样没发给出一个完全定义。但是最近看书了解到，ThoughtWork的首席科学家--马丁 福勒（Martin Fowler）先生，对于微服务的定义，似乎比较容易理解：

微服务架构师一种架构模式，它是倡导将单一应用程序划分为一组小的服务，服务之间互相协调工作，互相配合，为用户提供最终的价值。每一服务运行在其独立的进程中，服务和服务之间采取轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每一个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境，类生产环境等。另外，应尽量避免统一的，集中式服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建。

在进行XCD项目第二次的重构中，其实个人已经想进行模块化进行分组件，可惜也只是个人意愿，但是当找到一个可以说的来的伙伴的时候，这个计划就提上日程了，并且付之行动了。第三次重构。独立服务，将每一个业务功能模块进行服务化，这个就是微服务。这就是为什么要选择微服务。当你要进行为微服务组件的时候，首先你要你有一个或者二个赞同你的人，并且愿意和你一起付之行动和思考。并且一起考虑微服务你需要的各种技术点攻破。

微服务多微才够微

微服务架构是通过特定业务领域的分析和构建的，并且将负责的应用分类成一个个小并且专一，耦合度地并且可以高度自治的一组服务，每一个服务都是一个很小的应用，那么微服务中提到的微，到底什么样的“微”才是真正的微呢？

其实讨论“微”的话，是一个很长的话题，这里我只是进行个人理解进行说明：

微：不是代码级别的微，而是业务基本的。举一个🌰：订单，但是订单里面包含了各种复杂的模块。会和钱挂钩，会和库存挂钩，会和配送挂钩，会和收货挂钩。那么怎么切分这个微。其实正如一句老话“适合自己团队的才是最好的”。这个没有一个标准。但是我个人是会按照模块进行划分。订单就是订单，付款就是付款，库存就是库存。每一个是一个独立的。

微服务的独立性

微服务的独立性，在于我们一个个业务模块上线的时候，一个个模块都是一个独立的应用或者叫做服务，我们不必关心之前的服务，我们只要把这个新上线的服务进行开发，测试，部署就可以了。

用二张图进行说明：

耦合度高

其实看这张图的时候，我往往醉了，因为这个就是我第二次改版的最后结果。

独立性高

其实这个就是现在的架构，我们保证每一个服务都是独立的，即使我业务发生变化，但是我对于的API接口参数还是不变的。也只是我服务内部发生变化。

说了这么多，其实大家会发现我们的一起是围绕着服务进行架构的。那么为什么不用SOA呢？

微服务和SOA

其实微服务不是一个全新的概念，你会发现他的很多理念和SOA一致。

SOA和微服务比较

微服务的本质

本质，指本身的形体，本来的形体；指事物本身所固有的根本的属性。语出晋刘智《论天》：“言闇虚者，以为当日之冲，地体之荫，日光不至，谓之闇虚。凡光之所照，光体小於蔽，则大於本质。”本质可使人们脱离具体的形象进行创新活动。  ---百度百科

一：我们可以围绕业务组件我们的团队，对于某一快业务，我们可以指定一个对当前业务很熟悉的担当模块组长，进行开发。

二：关注产品而非项目，对于我们一直做项目的人来说，产品项目有时候傻傻分不清楚。因为对于项目而言，我的开发周期，是在一个项目上线的点将项目完成，并且验收成果，就可以资源释放。这样人员的成长是很小的，但是微服务就不同，微服务倡导的是采取产品的模式惊喜团队组建，这样一个段杜复杂整个服务的生命周期，是从分析，开发，测试，并且运维来完成整个开发周期的。

三：技术多样性，这个对于开发人员而言，是一个很大的挑战，因为以前一个项目可能只有Java，或者C#等高级面向对象的语言一种，但是微服务就不同，它会更具不同的业务，自己进行开发语言选择。

微服务不是银弹

我已经说了很多微服务的好处，但是微服务不是银弹，我们要考虑实施微服务的时候要考虑以下问题：

1.分布式系统的复杂度

2.运维成本

3.自动化部署

4.服务之间依赖测试

5.服务之间依赖管理

6.分布式事务管理

最近很偷懒，本来这个想了好长时间，但是一直没写。想想还是写了。并且在下次写的时候会把XCD项目中对于上面提及的问题，会说明我和我的小伙伴是怎么做的。

以上的内容有一些事参考于网上进行了整理。并且说明了一下个人意见。