毫无疑问，微服务成为现在最受欢迎的架构，闭塞的我还是去年才开始听说和接触，缘于某个项目的供应商使用了Springboot，走的时候交接给我。其实好像到现在也没有完全理解微服务的含义和价值，反省反省……

        下面摘抄一些优秀博文的讲解和总结~

      --------------------------------------------------------------------摘抄分割线-----------------------------------------------------------------------------------------

1. 架构

        微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。

        微服务的概念是相对于传统的整体架构而言的，如下面两张图：

        应用组件封装的方式是整体架构与微服务架构的主要差异，微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界，其目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市场。

2. 特性

微服务架构有以下的一些通用特性，接下来摘抄一些比较常见的：

（1）应用组件化

组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。

（2）围绕业务能力组织服务

微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）

（3）产品而非项目模式

传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。

（4）“去中心化”治理

整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。

3. 一个简单的例子

4. 优点

（1）每个服务都比较简单，只关注于一个业务功能。

（2）微服务架构方式是松耦合的，可以提供更高的灵活性。

（3）微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

（4）每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。

（5）微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

5. 缺点

微服务的缺点主要原因在于其整体架构增加了系统的复杂性

（1）运维开销及成本增加

整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。

（2）隐式接口及接口匹配问题

系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。

（3）代码重复

某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

（4）分布式系统的复杂性

作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

（5）异步机制

微服务往往使用异步编程、消息与并行机制，如果应用存在分布式事务处理，其实现机制会变得复杂化。

6. 取舍

（1）需要避免为了“微服务”而“微服务”。

（2）微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

摘抄自：微服务架构(一)：什么是微服务