聚合数据的微服务架构实践聚合数据孙辉2016微服务架构的优缺点以及适用场景微服务架构的持续集成及交付微服务架构的商业价值微服务架构可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。单体式设计模式客户端界面数据库服务端应用由HTML、Javascript组成，使用浏览器进行访问，或者移动应用展示端由许多的表组件构成一个通用的、相互关联的数据管理系统服务端应用处理HTTP请求、执行领域逻辑、检索并更新数据库中的数据、使用适当的HTML视图发送给客户端单体式设计模式单体式设计模式02030401当项目变得越来越大之后，开发、部署和维护都会变得异常艰难，项目组成员也无法搞懂这些代码。开发效率会急速降低，应用越大，启动速度，各方面都会备受影响，降低效率。持续开发变得越来越艰难，进而，自动化测试，持续部署都会变得艰难可靠性降低，你可以想象下，你曾经遇到的那些大型项目，想换个技术和框架，简直是灾难单体式设计模式的不足之处当一个应用开发之初的时候，单体式开发并没有什么问题，相反还是很简单，容易的，但是当这个产品逐渐成长为一个大怪物的时候，问题也就逐渐开始展现了。微服务架构微服务架构的优点通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化...
