微服务不仅仅是技术架构。很多同学一说起微服务就说是技术架构。有的推荐Dubbo，有的推荐SpringCloud。和分布式微服务。首先，我认为微服务是一种分布式框架。上的微服务。net平台如此火爆，似乎根本说不过去。没有Java里的SpringCloud流行，但是据说可以用SpringCloud来开发。NetCore应用程序。NETCore是专门为模块化微服务架构设计的。
java微服务和分布式的区别有哪些？
这个问题已经收藏了一个多月了，一直在考虑如何回答这个问题，总结了很长时间终于有了一些感悟之前一直都是只可意会不可言传的感觉，和大家分享一下，如果有不同的建议，欢迎大家留言指正。分布式和微服务首先 ，我认为微服务就是分布式框架的一种。分布式的思想就是把一个系统的不同模块，部署在不同的服务器上，以应对高并发的问题。
SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合编排实现业务流程通常在SOA架构中，ESB企业服务总线扮演了重要的角色。微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线去中心化，部署粒度更细，服务扩展更灵活。微服务不只是技术架构很多同学一说微服务，就说这是一种技术架构，有的推荐使用Dubbo，有的推荐使用Spring Cloud。
我认为，微服务不单单是一种技术架构，也涉及到了管理组织架构。大多数的公司，需求开发测试运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想在微服务的架构下，一个服务应该是由一个团队全权负责的。不过组织架构方面的事情，真的不是我们能说了算的。必须要用微服务？我觉得没有必要为了微服务，而微服务有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造...架构设计还是要根据需求背景团队开发能力软硬件实力综合来考虑。
系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。微服务架构概述微服务架构本质是单个业务系统彻底的组件化前端，逻辑层，数据库解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。
微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。我们可以先看下从单体应用到微服务架构的变化图。
把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述微服务可以在自己的程序中运行，并通过轻量级设备与HTTP型API进行沟通。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构在现有系统中分布一个API区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。
如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。
如果你读完福勒的整篇文章，你会发现其中的指导性建议非常实用。当决定将所有组件组合在一起时，开发人员需要非常有信心，这些组件都将发生变化，规模也将发生变化。服务粒度越粗，越难符合规定的原则。服务粒度越细，减少变更和负载的影响就越灵活。但是利弊权衡很复杂，要在分配和资本模型的基础上考虑基础设施的成本。
