微服务架构在近几年一直很热门，尤其是随着敏捷开发、持续集成交付、DevOps、云技术、虚拟技术docker化等的深入人心，经常能在技术论坛，博客上看到相应的文章推送。正好现在我们之间使用的也是微服务架构，将一个原本巨大的单体应用进行拆分（比如有基础服务，用户中心，有提供给PC,H5的服务等），用RPC框架HSF进行微服务之间的通讯以及服务治理。于是我对微服务的概念有了一定的体会，想结合自己看过的一些文章对微服务的概述进行一个总结。
一.传统的单体应用
传统的开发单体式应用，随着系统变得越来越大，最终会达到一个临界点，作为一个单体（monolith）它变得难以管理。每一行代码的添加，都会让系统变得更加难以理解、变更和重用。架构图如下： 
应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。
一个简单的应用会随着时间推移逐渐变大，单体式应用的不足有：
1. 敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。
2. 单体式应用也会降低开发速度。应用越大，启动时间会越长。
3. 复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。
4. 单体式应用在不同模块发生资源冲突时，扩展将会非常困难。
5. 单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。
6. 单体式应用使得采用新架构和语言非常困难。
总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。
那么如何应对呢？
二.微服务架构
微服务架构是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
处理复杂事物，其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。我个人认为微服务化本身包含两层意思，一层是拆，将大的服务拆成小的服务粒度，通过远程调用解决依赖。但同时它也有另外一层意思，就是合，就是整个系统的微服务的所有组件之间应该是一个整体的分布式系统，按集群化的方式来设计，服务之间能互相感知，进行自动化协作。
一个微服务一般完成某个特定的功能，比如下单管理、用户中心管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。
比如，一个前面描述系统可能的分解如下： 
每一个应用功能区都使用微服务完成，另外，Web应用会被拆分成一系列简单的Web应用（比如一个对乘客，一个对出租车驾驶员）。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务，而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，可以通过NGINX方便实现，后续文章将会介绍到API Gateway。
运行时，行程管理服务由多个服务实例构成。每一个服务实例都是一个Docker容器。为了保证高可用，这些容器一般都运行在多个云VM上。服务实例前是一层诸如NGINX的负载均衡器，他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求，例如缓存、权限控制、API统计和监控。
这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。
三.微服务和SOA
实际上，微服务架构并不是一个全新的概念。仔细分析SOA的概念，就会发现，其和我们今天所谈到的微服务思想几乎一致。那在SOA诞生这么多年后，为什么又提出了微服务架构呢？
鉴于过去十几年互联网行业的高速发展，以及敏捷、持续集成、持续交付、DevOps，云技术等的深入人心，服务架构的开发、测试、部署以及监控等，相比我们提到的传统的SOA实现，已经大相径庭，主要区别如下表所示：
| SOA实现 | 微服务架构实现 |
|---|---|
| 企业级，自顶向下开展实施 | 团队级，自底向上开展实施 |
| 服务由多个子系统组成，粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（ESB/WS/SOAP） | 集成方式简单（HTTP/REST/JSON） |
| 单块架构系统，相互依赖，部署复杂 | 服务都能独立部署 |
四.微服务架构的好处
- 复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
- 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
- 技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，*选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。
- 容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
- 扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
五.微服务架构的不足
- 运营开销。更多的服务也就意味着更多的运营，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
- DevOps要求。使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。
- 隐式接口。服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
- 重复劳动。在很多的服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。
- 分布式系统的复杂性。微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
- 事务、异步、测试面临挑战。跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。
六.微服务技术关注点
要实现一个微服务的架构，我们需要关注的技术点包括：服务注册、发现、负载均衡和健康检查，前端路由(网关)，容错，服务框架的选择，动态配置管理等模块。这些模块可以组成一个简化的微服务架构图如下： 
除了微服务所需要的基础组件之外，还提供了分布式消息组件，分库分表组件，分布式调度组件等企业开发常用的中间件。 
七.总结
构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。随着用户需求个性化、产品生命周期变短，微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。
文献参考
1. 解析微服务架构（二）微服务架构综述
2. 微服务实战（一）：微服务架构的优势与不足