我很热爱技术，但确没有机会去梦想的地方证明自己。工作快两年了，现在在一个二线城市，基本没有技术提升路线可言，仅仅拿着一份不高不低的工资。看着曾经的同学都去了自己梦想的地方大展拳脚，我很羡慕。虽然客观条件有所限制，但我还是想以一个技术人的身份继续努力下去，找回对技术的热爱与追求，为本就短暂的职业生涯留下点什么。由此初衷我准备开始我的【从零开始搭建后端微服务架构】系列。虽然接触不到互联网，但我还是想证明，我是一名优秀的互联网技术人。

我要搭建的系统是我曾经负责过但却因为合同等客观原因流产掉的一个项目，我认为项目非常有技术挑战性，所以就在这里把它实现掉。本系列着重记录搭建的点滴历程，我会尽可能深挖用到的每项技术，但可能并不能作为某项技术的参考文档（我会努力追求这一点）。

本人才疏学浅，系列文章也是凭借自己的理论知识一步步构建，如果有不对之处希望大家可以多多指出，与我交流（qq:746411774）。

---

项目介绍

这个项目是为一家医疗企业定制的数字化系统，该医疗企业号称拥有亿级的用户群体，整个系统设计需要满足当前的用户体量。新系统不但要开发新的功能，还要整合一部分老系统。整个系统有供C端用户使用的app（类似于阿里健康，丁香医生等），意在让之前主打B端G端的医疗企业在C端有所作为；有供B端使用的app，web网页，意在让合作伙伴能更加直观高效的获取信息；有供G端使用的app，web网页，意在让政府可以更方便的监管。话不多说，先来看我为这个项目设计的架构规划图（可能涉及商业机密，已经简略掉部分业务流程，主要突出技术架构）：

业务及技术架构介绍

cdn/负载均衡层介绍

业务层面：

根据业务方提供的信息，该公司拥有亿级客户，虽然忠实用户只占小部分，但也有三四百万。流量输入主要有两方面：一方面是终端用户使用终端产生的流量，另一方面是接收物联网设备和第三方系统的数据。估算整个系统的日pv应该在一千万左右，并且考虑到以后的增长，需要设计一个可扩展的弹性架构。

技术层面：

为了满足企业当前已有用户体量和以后野蛮生长的需要，整个系统在入口层使用lvs/f5和nginx/netty搭建了二级负载均衡体系，并且采用动静分离将静态资源上提到cdn中，既可以减轻系统访问压力，也可以提升访问速度。这种方式已经可以保证当前系统日常的稳定运行，如果出现类似于双十一的流量激增，还可以在lvs之上加入dns动态轮询，横向扩展多个lvs/f5和nginx/netty二级负载均衡体系。

*：这里使用netty主要是为了与nginx互补，nginx主要用来做http/https请求的转发，netty主要用来处理物联网设备上传的数据，在物联网行业，总会出现很多乱七八糟的协议，这种协议用nginx并不能很好的处理，而采用netty可以更好的自定义解析方式，让我们的系统更加灵活。由于netty只是一个高性能的通信框架，虽然性能上不输nignx，但是在功能上确没有nginx丰富，在代码中再去开发一套负载均衡和转发的逻辑会有很大的困难，所以我们这里采用netty+rocketmq的方式，netty只管解析协议内容，解析完成之后就灌入rocketmq，由后端服务自行消费。

网关/服务层/管理系统/基础支撑介绍

业务层面

本系统从业务层面划分主要有一下几个模块：

1.样本模块

2.血液模块

3.疫苗模块

4.健康管理模块

样本指的是生物样本，该企业拥有大量的生物样本，依靠该样本体量开展了一系列的业务，比如样本展览，样本研究，样本状态监控等科研和产业数字化的需求；血液指的是人体血液，该公司存有一个血液库，所涉及的业务与样本相同，基本也是一些科研和产业数字化的需求；疫苗指的是我们平时接种的疫苗，该公司有一个疫苗库，并且依托这个疫苗库开展了疫苗接种的业务，该模块的业务一方面是科研和产业数字化的需要，另一方面是直接接触C端的疫苗预约，疫苗接种等业务；健康管理是指用户健康管家，这也是该公司发力C端的主攻点之一，本模块依托前面三个模块的基础设施，为用户提供健康体验和内容服务，健康体验比如用户可以在app上输入自己的体检报告，然后app可以为用户提供定制化的健康管理计划。内容服务比如提供健康小常识等。

技术层面

基于当前业务，我将4条业务线拆分成两大类，一类是后端的管理系统用来做数据维护，另一类是服务提供组件，用来为终端提供接口，供终端调用。而这两大类都需要基础服务模块提供支持。

此外，我又从四条业务线中抽象出了两个模块，用户模块和疫苗预约模块。

用户模块：由于该系统用户基数比较大，所以单独将用户模块从各个系统中抽离出来单独形成一个微服务组件，其数据管理由平台管理系统提供。

疫苗预约模块：疫苗预约接种功能在其公司之前的运作当中就比较火爆，其全国有3000多个接种点，都可以支持预约、接种。高峰期的并发量比较高，所以这部分业务我单独拆分出来形成一个微服务组件，其数据管理还是放在样本/疫苗/血液管理系统中。

该部分主要采用springcloud技术栈去构建服务体系，内部通信采用http的方式。这里其实在http与rpc的选择上有些纠结，但最终还是选择了http。说一下我的原因，dubbo相对于http来说显得更重量级一些，虽然在很多场景下它拥有更加全面的功能，比如调用方便，自动重试，自动负载均衡等，但却会增加系统的复杂度和耦合程度，并且在接口频繁变动的情况下会非常笨重，我还是希望我的系统更加轻量化，所以也就在效率和易用性上做了牺牲。其负载均衡、限流、容灾等特性通过springcloud的hystrix，ribbon等组件弥补。

数据层

业务层面

本系统需要提供的业务功能有：1.数据持久化  2.大数据分析  3.站内全文搜索（坑逼的需求）4.接入区块链做疫苗信息溯源

技术层面

为满足以上的需求：

1.持久化

mysql主要用来存结构化的数据，比如用户信息等强关系的信息

mongodb主要用来存储物联设备信息等，主要是保证灵活性（虽然mysql8也开始支持了json数据类型，开始朝nosql方向偏移，但是功能还很不完善，无法代替mongodb）。

2.大数据分析：

hdfs主要用来存储大数据分析需要的数据，后面接入spark，hbase等大数据工具做用户画像和科研分析

3.全文搜索

使用es来做全文搜索

4.区块链

这里暂时把区块链也归为数据层的一部分，使用以太坊作为底层存储

5.虽然业务没提，但是不能忘记redis

redis用来做缓存，session共享，分布式协调（分布式锁等一些乱七八糟的活）

 

我的任务

负责项目整体的技术流程设计、选型，为每种业务场景设计有针对性的解决方案，保证系统安全稳定的运行。

我的设计流程

第一阶段：

系统入口设计，也就是cdn，负载均衡层面的设计。

第二阶段：

数据库选型，这个阶段决定数据库层面使用何种数据库，如何针对项目需求设计数据库集群方案，将业务的基础数据库层面的东西先打通，为业务涉及提供支撑。

第三阶段：

       基础支撑设计，比如系统中使用的mq，kafka，config等组件的设计，也是为后面的业务设计打下基础

第四阶段：

       具体业务设计，有如下两个方面，

      1.定下每个模块中的代码规范和设计基调。

       2.对复杂或技术要求较高的业务场景做针对性分析，单个击破。

硬件基础

实体服务器若干台（本身就是臆想，所以想要几台就要几台）

云产品若干

更新频率

由于本人技术有限，架构过程需要查阅相关资料并整理，暂定每周日晚更新一次。

下期预告

系统的总入口设计，使用lvs/f5+nginx/netty两层负载体系打造系统入口