- 什么是微服务
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务中的“微”指的是组件的粒度，而非暴露接口的粒度。
- 微服务架构的一些通用特性
根据MartinFowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：
1.通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
2.围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。
3.产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
4.智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
5.“去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
6.“去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
7.基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
8.故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
9.演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。
- 微服务架构的优点：
1.每个服务都比较简单，只关注于一个业务功能。
2.微服务架构方式是松耦合的，可以提供更高的灵活性。
3.微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
4.每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
5.微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
6.故障隔离。
7.高效利用资源。
8.可独立部署、升级、伸缩、替换
- 微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
1.运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。在添加了负载均衡与消息中间件后，进程的数量还会持续增加。
2.必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。开发团队需要非常关注运维与产品，因为基于微服务的应用与其环境上下文是非常紧密地集成到了一起的。由于很多服务可能都需要自己的数据存储，因此开发者还需要“搞清楚如何部署、运行、优化以及支持各种NoSQL产品”。
3.隐式接口及接口匹配问题：服务依赖于彼此间的接口进行通信。改变一个服务的接口会对其他服务造成影响。把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
4.代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。而代码重复“是非常不好的，因为每个代码实例都需要进行测试和维护”。一种解决方案是在服务间使用共享库，不过“在多语言环境下这就行不通了，而且引入了耦合就意味着服务需要并行发布来维护彼此间的隐式接口”。（个人认为，简单性也是一个非常重要的一个方面，简单就好）
5.分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
6.异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。如果要求某个操作必须是同步且具有事务的，那么这就非常复杂了，这要求我们得“管理好相关联的ID以及分布式事务，将各种动作绑定在一起”。
7.可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
- 微服务重构
在重构应用方面，可通过以下方法梳理微服务：
(1)每个REST服务是一个潜在的微服务；
(2)每个SOAP web服务或EJB是一个潜在的微服务,特别是无状态的session bean,需要将面向功能的接口重新设计为面向资产的接口，并使接口转变为RESTful形式；
(3)使用领域驱动设计(domain-driven design)发现企业资产，这些资产可能是微服务。
在重构数据方面，需要考虑以下几个方面：
(1)寻找与其他数据关联不大的数据孤岛，检查系统的实体-关系图；如果有与其他数据断开的数据，就是一个潜在的数据重构点；
(2)数据表非规范化，对高规范化数据库中非规范化一些数据表以将数据重组为更大的逻辑块，其目的是增加数据冗余度使其更容易被打破；
(3)反向批数据更新，对数据重构时需要考虑数据重构失败时可批量地将新数据反向导回旧的数据模式；
(4)使用主数据管理，对被广泛使用的数据实体组成一个单一的一致性视图，并开发相应的微服务与主数据一起工作；
(5)在SQL数据库中寻找存储在BLOB(二进制大对象)字段类型中的代码，转而将这些对象存储在NoSQL数据库中，例如以键值(Key-value)存储方式存储；
(6)寻找活跃的记录模式，与其他无关的Flat对象，使用文档模式数据库进行存储，例如Cloudant或Mongo等。
微服务重构后还需要重新打包应用，包括：
(1)分割应用的EAR文件并打包成独立的WAR文件；
(2)应用“一个容器一个服务”，分别部署每个WAR文件至其自有的WebSphereLiberty实例运行时或Docker容器中；
(3)分别构建、部署和管理,为每个WAR文件使用独立的DevOps管线,每个WAR文件独立伸缩和管理。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接
文章评论