泰涨知识 | 从0到1了解微服务架构设计及使用(上篇）

泰克教育

▲作者：泰克教育讲师周佳雪

《六韬之犬韬》中讲分合：“凡用兵之法，三军之众，必有分合之变”，“分合”乃御变之道。

当下盛行的微服务技术无非是在“分”与“合”之间的实践与细化。由上层来俯视下层为分；由下层来仰视上层为合；由外而内为分，由内而外为合，分即是合，合即是分，当分则分，当合则合，合乎自然。今天我们带着这种思想一起来看看什么是微服务。

自从Martin Fowler在2014年提出了Micro Service（微服务）的概念后，业界就卷起了一股关于微服务的热潮。

微服务是一种分布式系统架构，它建议我们将应用切分为更加细粒度的服务，并使每个服务的责任单一且可以独立部署，服务内部高内聚，隐含内部细节，服务之间低耦合，彼此相互隔离，此外，我们根据面向服务的业务领域来建模，对外提供统一的API接口。

微服务的思想不只是停留在开发阶段，它贯穿于设计、开发、测试、部署、运维等软件生命周期。

如此看来，当我们提到微服务，实际上它是一种架构思想，我们称之为“微服务架构”（MSAMicro Service Architecture）。接下来我们一起具体来看看微服务架构。

01应用架构演进

单体架构 -SOA架构 -微服务

1.1、 单体架构

在早期互联网发展中，一般采用单体开发模式，即将所有的功能都打包成在一个独立单元的应用程序。例如开发一个在线购物商城，单体开发模式最多把整个项目作前后端的分离，后端开发则是由一批程序员从数据库设计开始再到业务层如用户注册，店铺管理，商品管理，商品展示，订单支付，物流管理，评价系统等模块顺序延伸开发，最终所有模块开发完成的代码合并在一起统一编译部署上线。file:///C:\Users\XINGER~1\AppData\Local\Temp\ksohtml6180\wps17.png

传统应用架构存在的问题：

① 传统应用架构实际上是一个Monolith，整个应用都封装在一个webapp中，视为一个整体无法拆分；

② 应用修改某个Module，就需要部署整个应用；

③ 部署整个应用消耗的时间与对系统带来的开销过大，导致资源浪费；

④ 技术选型单一；

1.2、 SOA架构

不可否认，单体架构能够快速根据业务需求建设系统。但随着代码功能增加，代码逻辑越来越复杂，后继的交付周期变长、维护困难。这时就有一些企业从业务层面分割原有的系统，比如我们对购物网站分割成商品、用户、支付管理三个块。在这个阶段，SOA架构已经能将复杂的企业业务按照不同的，可重用的颗粒度进行划分，将IT资源整合成可操作、基于标准的服务供业务方调用。

但是SOA架构中均采用了ESB总线模式，这种总线模式在实施时会遇到很多问题，比如：ESB总线通常与某种技术栈是强绑定关系，导致遗留系统切换难、切换周期长；服务细粒度的确定；通信协议的选择；ESB总线的压力等。

ESB总线功能：

●监控与路由各个服务之间消息通信：补充库存；设备（POS机，打印机）维修替换；

●解决各个服务组件之间通讯故障：异常处理方式依赖事件队列，同步还是异步等因素；

●控制服务版本与部署：ESB使服务版本控制更灵活，提高可用性；

●完成任务如事件处理,数据转换与映射,消息与事件查询与排序,安全或异常处理,协议转环,保证服务通讯的质量；

1.3、 微服务架构

微服务架构诞生于SOA之上，提倡将单一的应用架构按照功能划分成更小细粒度的服务单元，服务之间采用RESTfulAPI进行通信，能够将服务单独部署到生产环境。

也就是说，微服务架构使我们技术选型的自由度更加宽广了，既然系统可拆分为多个服务，这样非常有利于我们对每个服务进行监控，可不断收集每个服务的性能指标数据，当某个服务出现性能瓶颈时，会发出预警，我们可随时水平的拓展该服务，以支撑更大的流量，而不至于复制整个系统。

由于服务之间彼此隔离，相互之间不会产生影响，因此我们可以借助技术的手段实现自动化部署，这样使得我们的整个部署过程更加高效。

file:///C:\Users\XINGER~1\AppData\Local\Temp\ksohtml6180\wps24.png

02微服务优缺点

优点：

• 可以使用不同的技术栈来构建服务，互联网和开源技术的发展，产生了众多的好工具；
• 可以灵活使用不同的工具应对适合的场景；
• 灵活扩展架构，故障彼此无感知；
• 易优化，微服务架构中单个服务的代码量不会很大，当需要重构或者修改这部分服务时就会容易很多；
  
• 
  
  

缺点：

• 由于业务模块拆分的更为细致，服务器的数量变大，运维团队压力变高；
• 稳定性下降，服务数量变多导致单个服务出现故障引起整个系统挂掉的概率增加；
• 服务故障点定为困难；
• 由于业务使用了不同的技术栈开发，对于运维人员的技术要求变高；
• 由于业务模块之间通信频繁，对网络的稳定性要求变高；
  
  

03微服务架构使用场景

对于传统的单体架构项目，不同的业务模式必须采取统一的技术方案及技术平台，每个业务模块也不能独立出来复用，系统中一个模块出现问题会导致整个系统不可用。

随着企业业务的复杂度不断提升，传统单体架构模式越来越臃肿，难以适应灵活多变的业务需求，微服务应用可以完美解决上述问题。

通过应用微服务化，企业可将一个臃肿的系统拆分成若干小的服务组件，组件之间的通讯采用轻量的协议完成，实现各组件生命周期管理的解耦。随着业务增长，服务会遇到各种意外情况，如：瞬时大规模并发访问、服务出错、入侵等情况。

使用微服务架构可以对服务做细粒度管控，支撑业务需求。微服务架构典型案例；

• 业务逻辑复杂的大中型应用系统，将公共模块做成共享的微服务，应用只需要开发特定业务逻辑和UI，如BOSS、CRM系统；
• 业务逻辑并不复杂，但有大量的流量访问，可以将其拆分成细粒度的微服务进行单独部署和伸缩，如电商系统；
  

下图为华为ServiceStage微服务应用解决方案：

ServiceStage提供了业内领先的微服务应用解决方案，具有以下优势：

• 支持原生ServiceComb、Spring Cloud、Dubbo和Service Mesh多种微服务框架，支持双栈模式（SDK和服务网格互通），无需更改业务代码直接托管上云；
• API First，支持基于Swagger的API管理；
• 支持多语言微服务，如JAVA、Go、.NET、Node.js、PHP、Python等；
• 提供服务中心、配置中心、仪表盘、灰度发布等功能；
• 提供容错、限流、降级、熔断、错误注入、黑白名单等全套微服务治理策略。可针对业务场景进行界面化操作，极大提高了服务治理的可用性；
• 实现Spring Cloud、ServiceComb Java Chassis和Go Chassis之间的互相发现。
  
  

未完待续

                               
登录/注册后可看大图

泰克618“年中钜惠 知识狂欢”即将来袭！

6月16日-6月26日

等你到来

参加 “HCIE万人计划” 狂欢节

限时秒杀、钜惠折扣

各种惊喜、各种礼品

重重豪礼等你来撩

最最最重要的是

6月16日20:00-24:00

HCIE精品课程

抄底价直播夜

让我们嗨购到底  ！！

直击底价、钻石课程、无限未来

HCIE精品课

为你的职场升迁保驾护航

助你成为新世纪最优秀的专业人才！！

☟☟☟

联系泰克教育微信号“ taikejiaoyu  ” 参与活动

或

识别下方海报