适合初学者对微服务的理解（重在概念）

一、微服务概念

1.1 单体架构及其不足

一个典型单体应用Java工程包含表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao，然后打成war包部署在Tomcat、Jetty等Servlet容器中运行，如图1-1所示
表 示 层：用于直接和用户交互，通常是UI、网页等
业务逻辑层：业务逻辑处理层，例如数据要经过业务逻辑层处理后，才能展现
数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据进行操作

在应用初始阶段，业务复杂度和业务体量都比较低，单体架构无论在开发速度上，还是运维难度上，还是服务器成本上都有显著优点。随着业务的发展和业务复杂度的提高，这种架构开始出现不足，主要体现在：
（1）业务越来越复杂，代码的可读性、可维护性和可拓展性下降
（2）用户越来越多，单体应用的并发能力有限
（3）业务扩张，复杂度增加，修改业务或增加业务会影响其他业务，测试难度越来越大。

1.2 单体架构使用集群及其不足

那么，将单体架构集群部署，是否更好些呢？
如图1-2：
（1）用负载均衡服务器分发高并发网络请求；
（2）通过添加缓存服务器以缓解数据库读取数据的压力；
（3）当有大量读写操作时，将数据库进行读写分离，能够改善数据库的负载能力。

单体服务集群化，有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善系统性能，但依然没有改变系统为单体架构的事实，还存在以下不足之处：
（1）依然为单体应用，代码的可读性和可维护性依然很差。
（2）面对海量的用户，数据库将会成为瓶颈。解决办法将使用分布式数据库，将数据库分库分表。
（3）持续交付能力差，业务越复杂，代码越多，修改或添加代码所需的时间越长。新人熟悉代码的时间长，成本高。
虽然在应用初期，单体应用从成本、开发时间和运维等方面有优势。但随着用户增加，单体架构暴露的缺点显而易见，已经不能满足复杂的业务和海量用户系统。于是，微服务架构应运而生。

1.3微服务简介

微服务大概从2017年开始在各大技术社区、博客、论坛和新闻报道中经常被提及，是程序员和架构师经常讨论的话题。“微服务”最初是由Martin Fowler在2014年写的一篇文章《MicroService》中提出来的。他的理解：
“简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。”
思考Martin Fowler对微服务的理解，总结微服务具有如下特点：
（1）按业务划分为一个独立运行的程序，即服务单元
（2）服务之间通过HTTP通信
（3）自动化部署
（4）可以用不同的编程语言构建微服务
（5）可以用不同的存储技术
（6） 服务集中化管理
（7）是一个分布式系统

下面按以上几点展开对微服务的阐述
1. 微服务多 “微”才合适？
“微”到什么程度？一直“微”下去，也不能“大事化小，小事化无”。
根据代码量来定义
根据开发时间长短来定义
根据业务大小来划分…（比较常用）
划分要求：服务单一职责
低耦合、高内聚
拓展性和复用性良好…
具体讲业务拆分到什么粒度，需要开发人员自己去决定

【常见实践一：统一服务层】
最粗犷的玩法，所有基础数据，都通过一个统一的服务来进行访问。在业务不是特别复杂的时候，这不失为一个快速分层的方案，一旦业务变得复杂，服务层会变得非常重，成为耦合焦点

【常见实践一：统一服务层2】
统一的服务层，用户信息，好友信息，群组信息，消息信息都通过这个服务层来访问

【常见实践二：一个子业务一个服务】
统一的服务层，用户信息，好友信息，群组信息，消息信息都通过这个服务层来访问。服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么？

加入一个高可用服务分发层（例如Service Mesh），并在协议设计时加入服务号，可以减少蜘蛛网状的依赖关系。