[golang 微服务] 1.单体式架构以及微服务架构介绍

一.单体架构

在了解微服务之前首先看看单体架构,单体架构在 中小企业内部用的是非常多的，当 业务不复杂， 团队规模不大的时候，单体架构比微服务架构具有 更高的生产率,比如2017年前的淘宝都是单体架构

1. 单体架构的程序部署在单台服务器

这种架构是目前中小企业用的最多的架构,其中 web服务（nginx）、 网站程序、 静态资源（图片）、 数据库(Mysql、Redis)都在 一台服务器上面,如果每天网站的访问IP在5万以下这种架构完全可以应付（服务器配置也有关系）

2. 单体架构的程序部署在多台服务器（负载均衡）

把程序部署到多台服务器上面，然后通过nginx配置负载均衡，当客户访问项目的时候随机的分配给不同的服务器处理响应，这样可以防止宕机，提升系统运行稳定性

3. 单体架构的程序部署在多台服务器（负载均衡+主从数据库）

这样的架构能轻松的应对每天几百万、上千万的访问量

当每天有上亿访问量，或者更高并发量的时候，上面的方法就有点力不存心了，这个时候就可以使用微服务架构

二.微服务架构

1. 概念

微服务架构是 一种具体的设计实现或者设计方案，是将 复杂的系统使用 组件化的方式进行 拆分，并使用 轻量级通讯方式进行整合的一种 设计方法. 通俗的讲就是把 单体架构项目(单一应用程序)抽离 成多个项目（一组小型服务），部署到 多台服务器,每个服务运行在自己的进程中，服务间通信采用的 轻量级通信机制（通常用HTTP资源API），这些服务围绕业务能力构建并且可通过 全自动部署机制独立部署,这些服务公用一个最小型的 集中式的管理，服务可用不同的语言进行开发，使用不同的数据储存技术

微服务架构定义的精髓，可以用一句话来描述，那就是“ 分而治之，合而用之”,将 复杂的系统进行拆分的方法，就是“分而治之”,分而治之，可以让复杂的事情变的简单，这很符合平时处理问题的方法。 使用轻 量级通讯等方式进行整合的设计，就是“合而用之”的方法，合而用之可以让 微小的力量变动强大

2. 什么是微服务

微服务是微服务架构 具体的实现方案，是通过微服务架构设计方法拆分出来的一个独立的组件化的小应用

如果用“茶壶煮饺子”来打比方的话，原来是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元

3. 微服务这个概念的由来

据说，早在2011年5月，在威尼斯附近的软件架构师讨论会上，就有人提出了微服务架构设计的概念，用它来描述与会者所见的一种通用的架构设计风格。时隔一年之后，在同一个讨论会上，大家决定将这种架构设计风格用微服 务架构来表示。起初，对微服务的概念，没有一个明确的定义，大家只能从各自的角度说出了微服务的理解和看法。

在2014年3月，詹姆斯·刘易斯（James Lewis）与马丁·福勒（Martin Fowler）所发表的一篇博客中，总结了微服务架构设计的一些共同特点，这应该是一个对微服务比较全面的描述。原文链接 https://martinfowler.com/articles/microservices.html ,这篇文章中认为： “简而言之，微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的。可以通过全自动部署机器独立部署。这些服务器可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理”

在这里可能会混淆一个点，那就是微服务和微服务架构，这是两个不同的概念，而平时说到

的微服务已经包含了这两个概念了，微服务架构是一种设计方法，而微服务这是指使用这种方法而设计的一个应用。所以必要对微服务的概念做出一个比较明确的定义。

微服务架构是将复杂的系统使用组件化的方式进行拆分，并使用轻量级通讯方式进行整合的一种设计方法

微服务是通过这种架构设计方法拆分出来的一个独立的组件化的小应用

微服务架构定义的精髓，可以用一句话来描述，那就是“分而治之，合而用之”。将复杂的系统进拆分的方法，就是“分而治之”。分而治之，可以让复杂的事情变的简单，这很符合我们平时处理问题的方法。 使用轻量级通讯等方式进行整合的设计，就是“合而用之”的方法，合而用之可以让微小的力量变动强大。

三.微服务架构和单体式架构区别

1. 单体式架构服务

单体架构的优点

• 部署简单：由于是完整的结构体，可以直接部署在一个服务器上即可

• 技术单一：项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发

• 用人成本低：单个程序员可以完成业务接口到数据库的整个流程

• 项目管理相对较易

• 测试相对简单直观

• 应用开发相对简单

• 横向扩展容易

单体架构的缺点

• 系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动，重启

• 周期边长

• 系统错误隔离性差，可用性差，任何一个模块的错误可能导致整个系统的宕机

• 可伸缩性差，系统的扩容只能对整个应用扩容，不能做到对整个功能点进行扩容

• 线上问题修复时间长，任何一个线上问题修复需要对整个应用系统进行全面升级

• 交付周期长(需求->设计->开发->测试->现场实施部署，就传统性质的企业而言)

2. 微服务

微服务的优点

• 易于开发和维护：一个服务只关注一个特定的业务功能，所以它业务清晰，代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用在被维持在一个可控的状态

• 单个服务启动快：单个服务代码量少，所以启动快

• 局部修改易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这个问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可

• 技术栈不受限：在微服务架构中，可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库Mysql，有的服务可以使用非关系型数据库redis。甚至可根据需求，部分服务使用JAVA开发，部分微服务使用Node.js开发

• 按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合微服务的特点，增加内存，升级CPU或增加节点

微服务的缺点

• 运维成本高

• 分部式复杂度高

• 接口成本高

• 重复性劳动

• 业务分离困难

3. 单体架构和微服务架构技术选型

单体架构已经经历了很多年的考验，2018年前互联网上95%的项目都是单体架构

(1).如果公司没有运维建议使用单体架构 （小公司）

(2).如果项目并发量不大建议使用单体架构 （一天只有几万的访问量）

(3).如果项目比较简单请建议用单体架构 （小项目）

(4).如果项目并发量非常大建议使用微服务架构或者serverless架构（比如：一码通系统、单车系统、物联网平台、物流系统）

(5).如果项目需求经常变化，公司经常要开展线上活动建议使用微服务架构

(6).单体架构和微服务架构技术选型需要根据实际情况分析）

SN	对比点	微服务架构	单体架构	结论
1	上手难度	API 接口调用	数据库共享或本地程序调用	单体架构胜
2	开发效率	早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大	早期工作量小，随着项目规模和时间的推移，效率大幅度下降	对于简单项目单体架构胜，对于复杂项目微服务架构胜
3	系统设计（高内聚低耦合）	每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易	以包的形式对代码进行模块划分，控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起	微服务架构胜
4	系统设计（扩展性）	独立开发新模块，通过API 与现有模块交互	在现有系统上修改，与现存业务逻辑高度耦合	微服务架构胜
5	需求变更响应速度	各个微服务组件独立更，容易实施敏捷开发方法	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
6	系统升级效率	各个微服务组件独立升级，上手和开发效率高，影响面小	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
7	运维效率	大系统被拆分为多个小系 统，部署和运维难度大， 但可以利用 DevOps 等方 式将运维工作自动化	简单直接	单体架构胜
8	码复用性	微服务组件可以在新项目中直接复用，包括前端页面	一般以共享库的形式复用后台代码	微服务架构胜
9	硬件需求	按需为不同业务模块伸缩资源节点，一个系统需部署多个微服务，需要启动多个运行容器	整个系统只需要一个运行容器，为整个系统分配资源	对于简单项目单体架构胜，对于复杂项目微服务架构胜
10	项目成本	项目早期和后期，成本变化曲线平缓	项目早期成本低，后期成本大	对于简单系统单体架构胜，对于复杂系统微服务架构胜
11	非功能需求	为单独的微服务按需调优，甚至更换实现方式和程序语言	为整个系统调优，牵一发而动全身	微服务架构胜
12	职责、成就感	拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队	职责不明确，容易产生扯皮行为	微服务架构胜
13	风险	大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险	系统是一个整体，一荣俱荣，一损俱损	微服务架构胜

4. 为什么要学微服务

(1).会单体架构学习微服务非常简单

(2).微服务是非常热门的话题，企业招聘中也越来越多的要求有微服务开发、架构能力的人才

(3).提升技术实力，增加职业转型的可能性

(4).微服务解决工作中软件研发难题，比如高并发

(5).微服务技术栈不受限、可以方便的和其他语言实现通信

(6).如果架构师或者项目管理人员微服务是必备技能

[下一节][golang 微服务] 2. RPC架构介绍以及通过RPC实现微服务