微服务架构简单概要

第一章：微服务架构概要

1.1什么是微服务：

马丁·福勒，他于2014年发表了一篇关于微服务的博客：https://martinfowler.com/microservices

微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。

1.2单体应用架构

单体应用架构概念

所谓单体应用架构，通俗来说就是把所有功能全部堆积在一起。这个应用大部分都是一个war包或者jar包。随着业务的发展，功能的增加，多年之后这个单体项目将变得越来越臃肿。

这样的单体应用在公司创建初期是一种比较好的方案，要快速增加新的功能或者部署发布都比较简单。不过，随着时间的推移，危机也越来慢慢的显露出来。任何一个bug都可能导致整个项目的瘫痪，正所谓牵一发而动全身。

单体架构图

单体体应用架构的优缺点：

优点：

易于开发&测试：

单个应用包含所有功能，不涉及多个应用的互联互调，便于在团队之间开发与测试。

易于部署：

只需将单个应用打成war或jar包，进行部署到Tomcat即可，运维起来比较方便。

易于整体扩展：

当应用负载压力大时，将这个应用复制几份，分别部署在不同的服务器上，再通过负载均衡即可提高应用的并发能力。

缺点：

复杂性高：

由于是单个应用，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。

技术债务：

随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。

阻碍技术创新：

对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

1.3微服务架构

微服务架构概念

微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。

微服务架构图:

微服务架构的优缺点:

优点:

1：服务的独立部署：每个服务都是一个独立的项目，可以独立部署，不依赖于其它服务，耦合性低。

2：职责专一，由专门的团队负责专门的服务：业务发展迅速时，研发人员也会越来越多，每个团队都可以负责对应的业务线，服务的拆分有利于团队之间的分工。

3：更适合敏捷开发：敏捷开发以用户的需求为核心，采用迭代，循序渐进的方式进行。服务的拆分可以快速的发布新版本，修改哪个服务只需要发布对应的服务即可，不需要整体重新发布。

劣势：

1：分布式部署，调用的复杂性高：单体应用的时候，所有模块之间的调用都是在本地进行的，在微服务中，每一个模块都是独立部署的，通过HTTP来进行通信，这当中会产生很多问题，比如网络问题，容错问题，调用关系等。

2：独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用mysql，评论服务可以用Mongodb，商品搜索服务可以使用ES。

3：测试的难度提升：服务和服务之间通过接口进行交互，当接口有改变的时候，对所有的调用方都有影响的，这时自动化测试就显得非常重要了，如果靠人工去一个个接口测试，那工作量太多了。需要强调的是，API接口文档的管理尤为重要。

4：运维难度的提升：在采用传统的单体应用的时候，我们可能只需要关注一个tomcat的集群，一个mysql的集群就可以了，但是在微服务架构下是行不通的，当业务增加时，服务也越来越多，服务的部署，监控将变得非常复杂，这个时候对于运维的要求就高了。

微服务架构总结：

1：微服务的核心就是将传统的单一应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事。

2：在 IDEA 工具中使用Maven构建的一个个独立的 Module ，也就是使用Spring Boot 开发的一个个小模块就是一个个微服务，将专业的事交给专业的模块来做。比如一个大型互联网项目可能有上百个微服务，将这些微服务集中起来构成一个大的系统，对外暴露服务进行调用与使用。

3：从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

1.4介绍微服务架构技术栈

搭建分布式微服务架构的技术栈