本文希望从技术角度来探讨下微服务，因此，不会过多地谈及如何根据业务进行微服务划分，更多是介绍微服务的相关技术，微服务的业务划分方法可参考“领域驱动设计“相关方法论。

微服务的两个程度

一、服务化

　　复杂的单体架构会有以下的挑战：

　　（1）项目启动初期，需要寻找一个能尽量涵盖所有需求的开发语言，技术选型难度高；

　　（2）工程庞大，组件、中间件繁多，编译时间长；开发环境复杂，需要安装大量的辅助软件，环境准备时间长；

　　（3）团队无效沟通多，沟通成本高；

　　（4）部署环境依赖大，某个组件的问题可能导致整个系统无法运行；

　　（5）新功能添加或者bug修复的时候，会影响现有功能，引发新的（未知）问题，添加单元测试难度大；

　　（6）版本回滚颗粒度大，灵活性差。

　　以上几点都是实际项目中遇到的问题，如果你也遇到了同样的问题，那么服务化是较好的解决方案。

　　服务化解耦后：

　　（1）微服务可以根据自身业务特征选择合适的开发语言或数据库；

　　（2）微服务的开发者只需要安装该服务相关的辅助软件；

　　（3）沟通多集中在微服务团队中，与周边（或公共）微服务有交集时才产生相应的沟通；

　　（4）部署环境依赖小，某个微服务部署失败仅影响该微服务（或周边几个微服务）；

　　（5）功能调整，如果接口没有调整，基本不会影响其它微服务，添加单元测试、接口测试难度低，自动化（回归）测试覆盖率高；

　　（6）版本回归最小单位为某个微服务，颗粒度小，可更好地实现蓝绿部署、A/B测试、灰度（金丝雀）发布。

二、容器化

　　容器（docker）具有轻量、环境依赖低、启动速度快等特点；

　　虚拟化技术（openstack）负责IaaS层（存储、计算、网络）资源的调度；

　　容器治理平台（Kubernetes、docker swarm）配合资源监控对容器进行灵活调度；

　　以上3种技术极大地提高了微服务的横向（弹性）伸缩以及高可用的能力，使微服务具备更好的高并发处理能力。

　　配合DevOps，CI/CD等工具及技术提升了团队快速响应、持续交付的能力。

　　我认为，团队应该基于产品或项目实际情况选择合适的微服务程度。

微服务基础技术架构

　　我认为，当前使用前后端分离的开发模式还是十分有好处的，关于前后端分离的描述，可参考我之前的《浅谈开发模式及架构发展》。

　　Web A/B/C/...是几个纯前端项目，可以根据实际情况在不同项目中使用Angularjs、Vuejs或Reactjs等框架进行开发；

　　API X/Y/Z/...是几个API项目，供Web或者App调用，可以根据实际情况使用.Net Core、Java或python等语言进行开发；

　　也可以根据带宽或性能需要，让Web或API启动多份示例。

　　基本交互：

　　浏览器经过网关从服务端获取网站的html及js（橙色箭头）；

　　Web通过url或ajax经过网关访问服务端API，App通过类Http Client方式经过网关访问服务端API（灰色箭头）；

　　API X/Y/Z/...注册到服务中心（蓝色箭头）；

　　Web A/B/C/...、API X/Y/Z/...从配置中心读取各自的配置（紫色箭头）；

　　API X通过服务中心调用API Z（绿色箭头）。

　　因此，微服务的三个基础组成部分分别是服务注册发现，配置管理以及网关。

服务注册发现

一、最简单的服务注册发现

　　我认为最简单的服务注册发现是直接通过IP端口进行访问，这种方式适用于单个实例的服务，但如果API Y是多个实例，那么需要借助类似虚拟IP（VIP）等技术。

二、基于中间件的服务注册发现

　　API Y实例1/2/.../n启动时，会把自己的信息注册到服务中心（自上报）；API X需要调用API Y，会先从服务中心中获取API Y服务实例的IP端口列表；然后根据特定的策略（随机，网络情况，权重等）筛选出一个实例进行调用，负载均衡是在客户端（调用方）实现的。

　　这种方式的典型代表是Spring Cloud Eureka，如果服务中心down掉了，那么会影响整个系统，因此，要保证服务中心的高可用；另外，需要有特定的jdk/sdk和服务中心进行交互，如Java的FeignClient（集成了ribbon实现服务的负载均衡），steeltoe的DiscoveryHttpClientHandler（随机选择实现服务的负载均衡），有一定的语言侵入性。

三、基于容器治理平台的服务注册发现

　　API Y实例1/2/.../n部署启动时，治理平台会给它们分配IP端口，并记录在服务中心；API X需要调用API Y，会基于dns，通过API Y的服务名或集群 IP（Cluster IP，类似于Virtual IP）加端口进行访问。负载均衡由治理平台负责，是在服务端（平台）实现的。

　　这种方式的典型代表是docker swarm以及Kubernetes，服务注册发现的高可用由平台保证，因为基于dns，普通的http客户端就可以进行Api访问，如java的restTemplate或C#的HttpClient，无语言侵入性，但负载均衡的灵活性比中间件的方式稍微低一些。

配置管理

一、最简单的配置管理

　　最简单的配置管理就是平时常用的配置管理，如java的application.properties、.net的web.config、.net core的appsettings.json等，基本是和应用程序一起，能够兼容多个环境（开发、测试、生产）。

　　但当我们的程序需要启用多份的时候，这种简单的配置管理方式遇到了挑战，配置的更新需要手动更新各个实例的配置文件，繁琐且容易出错（遗漏、修改错误或环境依赖）。

　　这也是微服务中面临的一个主要挑战。

二、基于中间件的配置管理

　　这种方式的典型代表是Spring Cloud Config Server。

　　API X、Y...会通过Url访问配置中心，通过心跳（2s）来确认配置中心的健康以及检测配置内容的更新。

　　其中，application.yaml用于保存各个微服务的公共配置，{服务名}.yaml用于保存微服务的私有配置。

　　和Eureka一样，使用者需要自己保证Config Server的高可用，否则，配置中心down掉的话，整个系统的配置信息就会乱套；另外，也需要有特定的jdk/sdk和配置中心进行交互；配置文件的格式基本也限制于yaml格式。

三、基于容器治理平台的配置管理

　　这种方式的典型代表是Kubernetes ConfigMap。

　　部署、升级、增加API X、Y...实例时，Kubernetes会按照设置，把对应的配置文件放置到容器（docker）指定的位置，也可以是环境变量。

　　配置中心的高可用由治理平台保证，微服务不需要使用特定的jdk/sdk和配置中心交互，只需要解析本地路径的某些文件，文件格式可以根据需要选择（json,xml,yaml,properties）。

　　微服务公共配置与私有配置也可以实现，但需要语言支持，比如.net core，详细的可以参考我之前的文章《你可能不知道的.Net Core Configuration》。

网关

　　网关作为微服务的统一出口，一般需要完成以下任务：反向代理，跨域处理，负载均衡，流量控制，缓存，日志，公共功能（如认证）等，常用的网关中间件有Nginx，Spring Cloud Zuul，Kong，Ocelot等。

　　或许有人会问，像公共功能（如认证）这些，在过滤器(filter)里做就好了啊，为什么要在网关做，没看出什么优势。I think it is a good call.

　　确实，像认证这些功能的确可以在过滤器里做，但是，如果过滤器需要升级，那么每个微服务都要进行升级；另外一种情况是，如果微服务是使用不同语言编写的，那么还需要提供多个版本的filter；更为恶劣的可能是该语言不支持filter，或者像单点登录这些公共模块没有提供该语言的jdk或sdk；还有一种比较特殊的情况是，可能在不同的环境系统需要有不同的认证机制，如对接第三方的认证系统。使用网关就能比较好的解决以上问题。