由于Martin Fowler和Chris Richardson两位大神的布道，及NetFlix和Amazon公司的实践，国内对于微服务的一些基础问题理解基本一致，但受限于自身单体应用的限制，过分到微服务架构，又要各想办法，具体问题具体看了。本篇描述一下微服务架构的基本概念及我的的一些理解。“微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每一个服务运行在其独立的进程中，服务和服务之间采用轻量级的通讯机制相互沟通（一般是基于HTTP的Restful API).每一个服务都围绕着具体的业务进行构建，而且可以被独立的部署到生产环境、类生产环境等。另外，应尽可能避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构"---- Martin Fowler的博客html
微服务的特征与界定
前端
单体应用 vs 微服务架构数据库
优势
编程
1:提高开发交流，每一个服务足够内聚，足够小，代码容易理解；
后端
2:服务独立测试、部署、升级、发布；
服务器
3:按需定制的DFX，资源利用率，每一个服务能够各自进行x扩展和z扩展，并且，每一个服务能够根据本身的须要部署到合适的硬件服务器上；每一个服务按4:须要选择HA的模式，选择接受服务的实例个数；
架构
5:容易扩大开发团队，能够针对每一个服务（service）组件开发团队；
负载均衡
6:提升容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
框架
7:新技术的应用，系统不会被长期限制在某个技术栈上；前后端分离
缺点
没有银弹，微服务提升了系统的复杂度；开发人员要处理分布式系统的复杂性；服务之间的分布式通讯问题；服务的注册与发现问题；服务之间的分布式事务问题；数据隔离再来的报表处理问题；服务之间的分布式一致性问题；服务管理的复杂性，服务的编排；不一样服务实例的管理。
Chris Richardson提出的微服务的三维扩展模型：
X轴，服务实例水平扩展，保证可靠性与性能；
Y轴，功能的扩展，服务单一职责，功能独立；
Z轴，数据分区，数据独立，可靠性保证；
通讯问题
微服务的拆分通常会带来IPC通讯的问题。通讯机制须要完备可靠，服务之间的通讯选择应尽可能单一，从两个维度对通讯的模式进行划分：
第一个维度是一对一仍是一对多：
一对一：每一个客户端请求有一个服务实例来响应。
一对多：每一个客户端请求有多个服务实例来响应。
第二个维度是这些交互式同步仍是异步：
同步模式：客户端请求须要服务端即时响应，甚至可能因为等待而阻塞。
异步模式：客户端请求不会阻塞进程，服务端的响应能够是非即时的。
微服务架构认为，服务间通讯应该就只有这几种模式。AC出于时延、编程模型等方面的考虑，提供了一套通讯机制，业务之间的通讯要按需选用。
服务的发现与注册
通常的微服务架构里都有两层API GetWay，一层是外部API GetWay，用于用户访问系统；一层是内部API GetWay，内部服务之间的API GetWay。内部API GetWay要解决的问题就是服务发现和服务注册。从这也能看出来，为何通讯的方式要尽可能单一，API GetWay有一项工做就是协议转换。
微服务多是HA主备的，也多是LB的，怎么找到一个服务？有两种思路，客户端发现（左图）,客户端去注册中心查询服务实例列表，自行选择；另外一种是服务端发现（右图），添加LB模块，客户端把请求发向LB，由LB根据负载均衡策略选择服务实例；
微服务注册表的典型实现:
ETCD : 是一个高可用，分布式的，一致性的，键值表，用于共享配置和服务发现。两个著名案例包括Kubernetes和Cloud Foundry。
ZK: 是一个普遍使用，为分布式应用提供高性能整合的服务。Apache ZooKeeper最初是Hadoop的子项目，如今已经变成顶级项目。
微服务架构的部署
微服务架构对于部署的要求：
部署速率，Amazon与NetFlix都有千个服务，每一个服务都有持续部署的要求，Amazon的服务每秒都会部署一次；
部署自动化，一切都要自动化，IaaS与PaaS解决I层与P层自动化部署，微服务有自动部署与运维工具，并实现Auto-Scaling；
部署提供基础机制，为实现分布式部署要求，部署机制通常都有资源池化、服务的生命周期来看，部署服务 与服务注册是一体的；
部署的粒度：
VM: 部署系统管理的VM的生命周期，如当前AC的iDeploy部署，把AC部署拆分为每一个VM的安装、配置与启动；这种方式粒度粗，支撑不了微服务的部署(除非一个服务占用一个VM);
App: 管理应用的生命周期及部署形态，生命周期分为部署、配置、启动、升级等，部署形态有主备、LB、Daemon等；
Container: 相比于APP，容器有更好的隔离性和移植性；
微服务：通常的微服务要么是APP，要么是Container，但AC就不是。受限于ONOS架构，咱们的服务是一组feature；
MS部署的解决方案：
TOSCA: 云应用拓扑标准，一种描述云化部署的DSL，我司主推一个标准，PaaS的部署系统和MANO用的都是TOSCA；
Kubernetes:Google开源的容器管理系统，提出了Pod/Service/Labels等概念，以ETCD为中心，PaaS基于K8S开发出了我司的云化部署平台；
Mesosphere:DCOS，数据中心操做系统，基于mesos实现资源池化，有自身的编排工具；分布式LAB基于DCOS的思想作出了一套部署与集群管理系统(HASEN)；
微服务的划分
微服务的划分主要是保证微服务功能内聚，职责单一。通常使用DDD(Domain Drive Design)的思想与方法对微服务进行划分，这种方法有点相似于数据库ER图的划分，不断分解数据，保证关系型数据库符合原子性、冗余性的范式要求。固然，微服务的划分比数据表划分更复杂，也没有微服务范式的概念，但思想是一致的。更多的内容，请参考《领域驱动设计》这本书。
分布式一致性
有两个大的思路：全局的分布式事务；事件驱动；
分布式事务就是如今AC的思路，在设计开发中；
事件驱动，忽略了事务的概念，由每一个服务在应用层面保存服务的状态，服务之间的通讯使用事件机制通知；此种方法能够保证微服务间的独立性，但把问题交给了服务的设计者；具体事件驱动的案例见参考材料；
数据隔离问题
微服务之间数据隔离能够保证服务的独立升级与部署，数据隔离有三个维度：
数据表级隔离；数据表之间独立，没有外键关系；
数据库级隔离；不一样服务有不一样的数据库；
DBMS级隔离；不一样服务有不一样的数据库管理系统；
通常作到数据库级隔离就能够了，服务之间的数据交换使用服务间接口。
从单体到微服务
微服务架构是一个衍生架构，都是从单体架构演化而来的。
由于微服务架构自己的复杂性，初创系统出于快速开发、快速验证的考虑，不多在一开始就使用微服务架构。加之微服务的概念在这两年才火，大型单体应用也是看到了开发与维护的成本在不断增长，才会有转型微服务的动力。所以，如何从单体到微服务是一个广泛问题。
从单体到微服务的原则：
逐步演进，不要所有重构。
所有重构，带来极大的成本和风险，系统会有很长的不稳按期。并且，最终的效果也不会很好，在设计时很难想到全部问题。微服务架构的演化思路应该是一步步铺基础设施，一点点拆分微服务。
演化建议（我的建议）
1. 不要增长新的耦合；
不要有编译依赖，如直接import其它模块的类；
使用版本建议的通讯方式，不要使用osgiservice，这个耦合仍是很强；不要直接访问其它模块的数据表；
避免没必要要的亲合性，注意特性之间的状态，如A特性访问B特性的2个请求有状态，那这两个特性实例就有亲合性；
2. 先后端分离；
先后端业务分离，前端之间不会耦合，能前端作的，就放在前端；
3. 独立的服务逐渐拆出；
逐步拆出功能独立的微服务，对有特殊DFX要求的微服务也能够优先拆出；
DevOps与微服务架构
DevOps是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才获得了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专注、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。
对于DevOps，MS不是必须的，但MS为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。因此，也有人称MS是DevOps架构。
目前，华为云对微服务的支持投入巨大，在国内率先支持Go语言服务框架！如今，围绕微服务正在如火如荼的开展一系列体验活动！
有兴趣的朋友能够前往查看！
https://activity.huaweicloud.com/cse/index.html?dfk