本文希望从技术角度来探讨下微服务，因此，不会过多地谈及如何根据业务进行微服务划分，更多是介绍微服务的相关技术，微服务的业务划分方法可参考“领域驱动设计“相关方法论。
微服务的两个程度
一、服务化
复杂的单体架构会有以下的挑战：
（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端口列表；然后根据特定的策略（随机，网络情况，权重等）筛选出一个实例进行调用，负载均衡是在客户端（调用方）实现的。
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；还有一种比较特殊的情况是，可能在不同的环境系统需要有不同的认证机制，如对接第三方的认证系统。使用网关就能比较好的解决以上问题。
下一代微服务
既然可以通过部署一个网关，让所有请求都经过它来实现一些公共的功能，那么有没有可能使微服务的请求经过一个特定的“层”，来实现一些特定的功能（如调用链、熔断，服务调用认证，请求限制等）呢？答案是肯定的。
我认为Kubernetes其中一个强大的设计是，它的最小单位是pod，而不是容器（container）；一个pod里面可以有多个容器，而且它们可以共享网络，共享存储。
可以通过在pod里面部署一个业务容器，同时也部署一个小型的sidecar容器，让请求到达业务容器之前，先经过sidecar容器（起到了filter的作用），在sidecar容器中实现调用链、熔断，服务调用认证，请求限制等功能，这样就可以通过基于部署的方式解决语言限制的问题。
目前可以选择Istio或Linkerd来实现上述效果。
简单总结
我认为，从架构的层面来看微服务架构，应该是这样的：
扩展性：降低复杂系统的耦合度、沟通成本以及系统复杂度，需求快速响应；
伸缩性：可以通过增加资源的方式来快速应对海量并发（仅仅是并发层面，大数据量还是需要根据业务进行分片或分割）；
稳定性：微服务治理平台，PaaS平台保证了系统的高可用性，可以降低业务的中断时间；
安全性：和传统架构的要求差别不大，但是由于网关和网格（Service Mesh）的存在，使得安全处理，APM等的实现更加简单。
另外，我认为微服务可以通过部署的方式来实现功能或模块的复用，一定程度上代替了过往通过jdk/sdk来实现共用的方式；使得开发更加灵活，也使得开发可以更加关注于业务，而非各种边边角角的公共（轮子）功能。