微服务架构学习精要（一）

一、架构师、技术专家区别

架构师关注知识的广度，而技术专家偏向某一个专业领域的深度。如果我们想成为一名架构师，那么不应该把所有的精力都投入在某个技术领域而是需要分散关注面，在众多领域都要有一定的深度。其次，架构师除了具备技术硬技能，还需要在沟通、组织、学习等技能做好发展。因为没有好的软实力，架构师则无法将自己的架构顺利移交程序，并指导他们落地。

架构师的职责是什么：制定规范+指导落地。就好像两条腿走路，左腿向前制定规范，右腿关注落地实施。

二、软件架构的演进

1、没有架构

早期的系统没有分层，所有界面、逻辑都混在一起，对于小型业务系统效率较高。但随着业务系统的扩展，可维护性很差。

2、基于MVC的分层架构

为便于同一个公司的业务开展，将程序架构分为了界面、控制、模型层。界面负责展现、控制层贯穿整个业务流程、模型主要是业务逻辑、数据逻辑。如在java中，曾经著名的SSH架构，Struts主要是界面、Hibernats主要是模型，Spring主要是控制层。

3、面向服务的SOA

将服务分拆为多个模块，中间有服务中间件，如IBM Websphere。臃肿的中间件，造成了效率下降、成本的上升。

4、更加拆分的微服务架构

为解决SOA的极端中心化、服务拆分颗粒度仍比较大的问题，以Docker的轻量化的技术加速了微服务的推广。

三、微服务与SOA的本质区别

微服务一向被认为是云中心化，但下图微服务的架构中，仍然有注册中心等中心组件。实际，微服务强调去带业务的中心，而非技术中心。例如，两业务模块通信不再通过SOA的复杂路由、数据转发。

四、如何进行微服务治理

1、梳理业务流程。业务需求是一切技术的根源，了解真实的业务流程，并将其疏理成为业务流程图。对于业务的疏理花再多的时间，也是值得的。

2、抽取公共服务模块。例如将用户管理、短信发送等所有业务都需要的模块首先抽取出来，作为公共的微服务模块。

3、定义业务服务。初期我们可以将业务服务的模块定义得大一些，后期再进行逐步的细分。业务模块应保障功能的相对独立，避免过多的模块间业务通信。

4、设计数据模型。也就是定义数据库的表结构、相互表之间的逻辑关系。该步骤如果设计不合理，后期的改造成本非常高。

5、定义微服务的接口。也就是相互间通信的共同语言。如用户微服务模块应有查询、注册、改密码等功能。同时建议接口API名应全局唯一，并带上版本号。这样便于后期注册中心的统一管理。

五、微服务部署架构

1、当开发代码、配置文件完成后，通过Docker镜像的封装，放入镜像仓库中。

2、当服务启动时，由部署中心根据业务负载、业务需求下发服务容器的加载。

3、服务容器启动完成后，将向注册中心注册服务。

六、微服务运行架构

1、当用户通过app、web调用微服务时，首次将通过“调用中心”，调用中心通过注册中心查询服务所在的ip、port。

2、随后调用中心将信息返回给用户，用户直接与调度中心进行反向代理的信息交互。微服务强调云中心化，调用中心参与业务越少越好。

3、服务容器在运行过程中，将运行日志写入日志中心，将彼此服务间的调用写入追踪中心，通过各中心的数据分析、记录作为后期的分析、优化依据。