如果所有的微服务都实现了，就有可能设计出50个微服务模块，100个接口和集成点。微服务架构下的运维难度增加。微服务架构实现后，运维的复杂度也翻倍。任何微服务模块故障都可能影响整个业务应用的功能使用。香港的服务器是免备案的，网站可以快速上线。2香港的服务器线是BGP多线，网通和网通没有区别。3香港的服务器是用的国际带宽，国外客户也能很好的访问网站。
为什么好多网站使用香港服务器？
国内所有上线的服务器都需要备案，国外的不需要备案但是美国的服务器到中国距离太远节点太多会造成访问太慢，而香港的地理优势和法律就决定了香港服务器盛行，好多美国的公司来香港提供服务器和其他的服务.且价格比国内的要便宜一点！香港服务器有以下几点优势！1香港服务器是免备案的，网站可以快速上线2香港服务器线路为BGP多线，没有南北网通电信之分，全国各地都能流畅访问3香港服务器是使用的国际带宽，所以国外客户也能很好的访问网站。
微服务为什么不需要esb？
首先我个人不认为微服务不需要ESB。两者是相互融合相互配合的，在不同的应用场景下发挥自身的优势，共同助力企业的发展。并且在微服务快速兴起的现在，ESB本身也在不断完善调整，比如，数通畅联的AEAI ESB本身就支持微服务架构的开发，实现了跟微服务架构的融合。其次微服务是近几年比较流行的新兴架构，更多的采用Restful接口而不是WebService，微服务类似于七巧板的组件，以小粒度为用户提供服务，用户可以根据自身的喜好自由组合配置服务组件，灵活的进行扩展。
但是微服务的局限在于因为服务量增多，管理成本增加，微服务难以用整体架构的形式进行支撑，个人认为微服务更加适用于快速响应如APP，前后端分离架构，互联网模式交互。ESB企业服务总线作为SOA中重要的承载物，可以说是企业信息的龙骨，通过ESB实现服务的消费者及提供者之间的联通与管理，实现服务的治理重组编排和代理等，可以有效的支撑企业级的信息化集成架构的落地。
系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。微服务架构概述微服务架构本质是单个业务系统彻底的组件化前端，逻辑层，数据库解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。
微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。我们可以先看下从单体应用到微服务架构的变化图。
把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述微服务可以在自己的程序中运行，并通过轻量级设备与HTTP型API进行沟通。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构在现有系统中分布一个API区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。
如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。
如果你读完福勒的整篇文章，你会发现其中的指导性建议非常实用。当决定将所有组件组合在一起时，开发人员需要非常有信心，这些组件都将发生变化，规模也将发生变化。服务粒度越粗，越难符合规定的原则。服务粒度越细，减少变更和负载的影响就越灵活。但是利弊权衡很复杂，要在分配和资本模型的基础上考虑基础设施的成本。
