这是学习的第五篇文章，在进行真正的业务拆分之前，我们来认识一下什么是SOA架构，什么是微服务。确定本系统拆分的几个部分。

单体架构

我们熟悉的单体MVC架构：

用户<—>表示层<—>业务层<—>数据访问层<—>数据库

单块结构的优缺点：

优点 缺点
功能划分清楚 功能仍然太大
层次关系良好 支付周期变长
每一层独立 升级风险高
部署简单 维护成本增加
技术单一 可伸缩性差
用人成本低 监控困难

单体架构如何转化为微服务

什么是SOA？

SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。

所以，SOA只是一种架构设计模式，SOAP，REST，RPC是根据这种设计模式构建出来的规范。其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。

SOA VS 微服务

话说1979年，又是一个春天，莆田乡下的赤脚医生吴大牛被改革的春风吹的心潮澎湃，说干就干，吴大牛趁着夜色朦胧找大队支书汇报了汇报思想，第二天就承包了村卫生室，开启了自己的在医疗圈的传奇历程。

乡村诊所大家都知道，没什么复杂的东东，房子只有一间，一个大柜台中间隔开，一半是诊疗兼候诊区，一半是药房，看病就直接找医生，如果前面有人就自己找个位子坐下，排队等一会，秩序倒也井然，看完病了医生直接给抓药，然后下一个继续，也不需要护士和药剂师，吴大牛一个人全部包办。

辛辛苦苦忙碌了十年，时间来到了八九年，又是一个春天，昔日的单身汉吴大牛已成为十里八乡的知名人物，媳妇娶上了不说，家里还增加了一对双胞胎儿子，二层的小洋房也甚是气派。可是也有烦心事，尽管乡村诊所扩大到了两间，媳妇还偶尔能去帮帮忙，但是医生还是只有自己一个，天天从早忙到晚挣的都是一份钱，想多挣点怎么办？吴大牛日思夜想，还真给他想出来一招，怎么办，扩大规模，多招几个医生一起干。原来吴大牛只能治头疼脑热和跌打损伤，现在新招了一个医科大学的毕业生刘小明专治感冒发烧，又从邻村请来了老大夫李阿花专治妇科病，现在一个普通的小诊所就变成了有三个独立科室加一个公共药房（吴大牛媳妇负责）的小医院了，吴大牛是外科主任兼院长，收入那可比之前翻了三番。人逢喜事精神爽，大牛院长请县里的书法名家为新医院书写了牌匾–“博爱医院”，挑了一个黄道吉日正式挂了上去。

一晃十年过去了，又是一个春天，吴大牛的博爱医院已经发展到了内科外科妇科五官科骨科生殖科六个科室，每个科室3到5名医生不等，也耗费巨资购进了血夜化验B超等先进仪器，大牛院长也早已脱离了医疗一线，成为了专职的管理者，但是医院的大事小事大家都找他，就这三十多号员工搞的他每天是焦头烂额，想再扩大规模实在是有心无力了。要说还是大学生有水平，老部下刘小明给大牛院长献了一计，把各个科室独立出去，让各个科室主任自己管理，大牛院长只管科室之间的协调和医院发展的大事，这样既能调动基层的积极性，又能把大牛院长解放出来扩大生产抓大事谋大事，岂不妙哉？就这样，博爱医院的新一轮改革轰轰烈烈的展开了。

又是一个十年，又是一个春天，大牛院长已成为本地知名的企业家，博爱医院也发展到了二十三个科室数百名员工，发展中也出现了新问题，由于各个科室独立挂号、收费、化验，有的科室整天忙忙碌碌效益好，有的科室就相对平庸些，连分到的各种检查仪器都不能满负荷运行，整个医院养了不少闲人。这时候大牛院长视野也开阔了，请来了管理专家进行了顶层设计，把原来分散到各个科室的非核心服务全部收归集中管理，把原来二十三个挂号窗口整合为十个，二十三个收费窗口整合为八个，集中布设在一楼大厅为全院服务，还把分散在各个科室的检查仪器集中起来成立独立的检验科，也为全院服务，这样人人有活干，整个医院的服务能力又上了一个新台阶，这轮改革后博爱医院通过了各级部门的鉴定成为了远近驰名的三甲医院，吴大牛也换身一变成为了博爱集团的CEO兼董事长，下一步就准备IPO上市了。

说到这里大家可能有点糊涂，这个跟微服务有嘛关系？在孙老师看来，大牛诊所的1.0阶段就相当于软件开发的单体结构，一个程序员打天下，从头编到尾，很难做大做强。大牛诊所的2.0阶段就相当于软件开发的垂直结构，各科室按照业务划分，很容易横向扩展。博爱医院的1.0阶段就相当于软件开发的SOA结构，除了药房（数据库）外各个服务独立提供（科室主任负责），但需要大牛院长（ESB总线）来协调。博爱医院的2.0阶段就相当于软件开发的微服务结构，公共服务院内共享，科室主任管理功能弱化（只管医生业务），优点是扩容方便，哪个部门缺人直接加，不用看上下游，资源利用率高，人员和设备效率高。为什么要变呢？小诊所有小诊所的活法，大医院有大医院的骄傲。无他，天下熙熙，皆为利来；天下攘攘，皆为利往。

设计原则

  • 拆分足够微：划分比较细，但是也不能太细，增加管理问题
  • 轻量级通信：rest，rpc等方式在网络上通信
  • 单一职责原则：高内聚，低耦合，确定服务边界

如何设计微服务系统

服务拆分----》服务注册----》服务发现----》服务消费(调用另外一个服务)----》统一入口(服务很多的时候需要有一个统一的入口)----》配置管理(管理每个服务的配置信息)----》熔断机制(保护系统避免崩溃)----》自动扩展(根据负荷自动扩展集群)

微服务拆分的意义

  • 易于实现
  • 易于部署
  • 易于维护
  • 易于更新

本天气预报系统可以拆分为：

  • 天气数据采集服务：数据采集和数据存储
  • 天气预报服务：数据展示
  • 天气数据API：数据查询
  • 城市数据API：数据查询