作为一名java架构师！你了解过这个架构模式吗？

设计微服务架构的一个主要难度是为服务组件选择正确的粗细粒度。如果服务组件设计的太粗糙，就彰显不了这种架构模式带来的好处（如部署、可扩展性、可测试性和松耦合）。但是，服务组件设计的过于细化，对服务组件编排要求更高，将你的微服务系统演变成面向服务的重量级体系结构，通常会带来缺点如复杂性、误导性、高开销，这些都是能在基于SOA的应用程序中找到的。

如果你发现你需要在应用程序的用户界面或API层内编排你的服务组件，那么你的服务组件可能设计的过于细化？ 同样，如果你发现你需要设计服务组件间的通信仅仅为处理单个请求，那么要么是你服务组件设计的太细化，要么从业务功能的角度来看，这两个服务组件没有界定正确。

服务间通信可能会增加组件之间多余的耦合度，这可以通过共享数据库来解决。例如，如果服务组件处理互联网订单需要客户信息，那它可以去数据库去检索必要的数据，而不是调用客户服务组件的内部功能。

共享数据库可以解决信息需求的问题，但是对于共享功能来说呢？如果服务组件需要包含在另一个服务组件中功能或需要让功能暴露给所有服务组件，这种情况下，有时你可能会复制共享功能到不同服务组件里（从而违反了DRY原则：不要重复同样功能）。 这在大多数情况下是相当普遍的做法，在实现微服务架构中，重复小部分业务逻辑代码，为了保持各个服务组件的独立性和实现独立部署。一些小型的实用工具类可能经常会有这类重复代码的状况。

如果你发现无论服务组件的粒度级别设计的如何，你仍然无法避免服务组件的编排。那么这说明微服务架构并不适合你的应用程序。由于这种模式的分布式特性，维护一个简单的跨服务最贱间的交易单元通常非常困难。这个过程通常需要设计某种交易恢复框架来回滚交易，这给该架构模式增加了很大的复杂性。

考量

微服务框架解决许多出现在单一应用或面向服务应用程序的常见问题。由于该框架下，主要的应用程序组件会被拆分成更小的，单独部署的模块，这增加了鲁棒性和可扩展性，并且更易达到程序交付的连续性。

这种框架另一个优点是它提供了实时部署的能力，从而大大减少产线部署麻烦。由于变更通常与特定服务的组件相关，只需要部署相应的服务组件即可。 如果服务组件是单例模式，那你可以在用户接口编写专门的代码用于检测运行中的热部署，并将用户重定向到错误页面或等待页面。 或者，你可以在实时部署期间，交换多个进出的服务组件实例，使得服务可以持续使用（这对分层体系结构来说非常困难）。

最后需要考虑一点是，由于微服务架构是分布式架构，和事件驱动架构一样，有一些相同的复杂问题待解决，包括协议创建、维护和管理，搭建远程系统和远程访问验证和授权。

模式分析

以下表格列出微服务系统通用的特点的评分和分析。每个特征的评分是基于模型的典型实施范例。

整体敏捷度

评分：高

分析：整体敏捷度是能够快速响应不断变化条件的能力。由于单元的分开部署特性，代码的更新通常会分离到具体的服务组件，这促成了快速和简单的部署性。当然，使用这种模式的应用具有松散耦合性，这又促进代码更新的方便性。

部署容易性

评分：高

分析：总的来说，由于这种模式具有松耦合的事件处理模块，因此容易部署。经纪人拓扑结构比起调度员拓扑结构更易部署，主要由于事件调度员组件会和事件处理模块相关联：任何事件处理模块的改动可能会导致事件调度员的改动，因此需要重部署这两个模块。

可测性

评分：高

分析：由于业务模块功能被分散到独立的应用中，测试可以在局部进行。测试一个业务模块会比测试整个单一应用程序更容易和可行。由于这种模式是松耦合的，很少可能在更新代码过程中，牵涉到应用的另外的业务模块，这也减小了为了一个小改动而对整个应用测试的压力。

性能

评分：低

分析：当然你可以用该模式设计出高性能的应用，但是，由于分布式的特性，这种模式本身并不是出于致力于更高效的特性。

可优化性

评分：高

分析：因为应用被分割成独立部署的单元，每个业务模块都可以被单独扩展，这就方便更好的优化应用。例如，股票交易应用中管理模块可能不需要太多调节、优化，由于使用量小；而交易设置业务模块可能需要更多的调节和优化，由于它被大部分交易应用所调用，因此要求其有高吞吐量。

易于开发

评分：高

分析：由于功能的实现被分散到独立的业务模块，开发范围分的更小，开发也变得更容易。很少有可能，开发者更改的一个业务模块，会影响到其他业务模块，因此减少不同开发者或团队的协助时间。

想要学习Dubbo框架、zookeper基本原理、redis分布式缓存、JVM性能优化，Nginx+apache+Tomcat集群部署、大数据hadoop,Hbase实时计算spark、storm、数据分析分词和权重等核心技术；需要的可以关注之后私信哈，记得要点赞转发噢！！！