Java fresh business platform - Micro Services Architecture Overview
Monomers present architectural issues
In traditional software technology architecture system, basically it will focus on business functions within a single application or a single process. Although the modern theory of software architecture and design principles has been extended for many years, but the actual technology derived slow pace of change and lack of motivation. The reason for the existence of complexity and diversity, I think the main reason is not a holistic solution that enables engineers to lower the risk of stability in the face, resolutely implement system reconfiguration. When the application system is particularly sensitive time scale with the rapid development of business, the importance of the system become more prominent, developers will reform the system, from the previous hesitate wandering, are becoming more conservative, only a continuation of past technical solutions , we will continue to accumulate function in the original system architecture. Such a system is like a pyramid tofu, the higher the risk of the stack. Therefore, when faced with great service pressure, the system has to expansion by the way, to support the deal with. As the saying goes, "small boat U-turn", "head disease cure head, foot disease, not the disease." Bloated system makes no specific expansion becomes, indeed affect the whole body. Because of differences in the operation of the service, which features specific performance bottleneck, because the service does not exist in isolation, so that there is a subjective assessment results and uncertainty, and this interaction under the action of such expansion becomes abnormal difficult, expansion can not be quantified, resulting in "bucket effect."
When increasing the size of application scenarios, in order to improve the development and implementation of efficiency, and make more elegant or appropriate solution to the problem is possible, developers will evaluate and select more advanced technology and promote evolution. Due to excessive application system centralizes all functions which can perform the required services, and dependent libraries are becoming huge, when you need to adapt new technologies, there is uncertainty not only rely on hard and difficult to deal with conflict, and thus make Code refactoring becomes extremely difficult, increasing the difficulty of adapting new technologies.
Because feature set in one, so that the application resource usage is becoming increasingly large, making continuous integration, regression testing, and deployment becomes increasingly difficult to distribute. For example, disk accounting application deployment package increases, so that compile, package, distribute and longer startup time, uncertainty becomes greater. When the application published on-line, the presence of functional defects, need to roll back, so trial and error and time costs become more expensive.
The more functions centralized system architecture, development projects, and the more dependent on the execution environment. This execution environment carries data, services, and configuration, should that part of the problem which, was forced to interrupt the development process, and continue to diagnose problems and debugging environment, making the rapid development to become inaccessible, not to mention the local development. Due to over-reliance on the environment, so that the stability of the system becomes more uncertain. First, due to the interdependence of service, and the service they depend on the environment, for developers and reduce dependence habit of unit testing, making testing part to reduce, or even more dependent on the integration testing. Second, when testing deployment of personnel to perform integration testing in a test environment, not only continue to reduce the success rate of deployment, and execution time is increasing, compress development time, and that could lead to lag. Not only increase the systemic risk, and increase the psychological burden. So to say, both the rapid development and testing have become more difficult.
The above analysis also just stay in those members familiar with the business and technology, when the rapid development of business, its growth rate and development of efficient than expanding, new recruitment and development are essential tools. When faced with such a huge and complex system applications, business and technical knowledge required to become particularly hybridity, the couple had a "tower alone look, do Wandering Road" feeling, the learning curve is steep. In the actual implementation process, document integrity and systematic guidance are insufficient.
How to solve the existing problems monomer architecture
Reality monomer applications has brought us:
- Expansion difficult (Problems in scalability)
- Deployment difficulty (Problems in deployment)
- Posted rollback difficult (Problems in release rollback)
- Difficulties in adapting new technology (Problems in adopting new technologies)
- Rapid development difficulties (Problems in RAD)
- Test difficulty (Problems in testing)
- Learning difficulties (Problems in learning)
Indeed, in addressing the issue of single applications, a few years ago, there have been corresponding solutions, such as SOA technical route.
SOA to solve a real problem, and that is the decoupling between the service and the service, the service call in the old process, transformed into a call between the service through a network protocol. From the early invented CORBA, RMI, COM +, XML-PPC technology, but the problem also appears, due to the binding of these technologies in a certain technology or platform, part of the Java platform technology such as RMI, COM + part of Microsoft's technology system, XML = PRC is no uniform standard protocol, and therefore strongly for platform-independent protocol voice communication needs, then some of the typical technology start to appear, such as WebServices and MessageQueue. As well as their master technical ESB.
Which represents the technology has: WSDL (Web Service Definition Language), SOAP (Simple Object Access Prototol) technology. Because of these relatively bulky communication protocol standard, although still widely used, but will be phased out is the trend.
Why not choose SOA and selected micro service
Service-Oriented Architecture (SOA) VS Micro Services
Similar
- Service (Service-Oriented) for
- Loosely coupled (Loose-Coupling)
- Self-contained (Self-Contained)
- Platform independence (Independent Platform)
difference
- Atomicity (Atomic)
- Autonomy (Autonomous)
- Development of operation and maintenance system (DevOps)
- Lightweight (Lightweight)
- Communication protocol (Communication Protocol)
Micro SOA service granularity is small, precisely because of the huge SOA system, it is impossible to achieve a better atomicity, and the way it uses the unified rule, such as large-scale solutions ESB. Such technology selection for a single service can not achieve self-management, team invisibly increase the operation and maintenance costs. Developers are not well implemented DevOps techniques. At the same time, SOA using WSDL, SOAP and other heavyweight communication protocol, increased development costs and performance loss. In the micro-services, most service REST API by way of exposure, which greatly reduces the cost of adaptation.
Trend Micro service
Let's look at the results of it google and Baidu statistics
Figure (1) Google search interest in spring boot
spring boot and spring cloud is to do the best micro-services partner. From the chart (1), we can see spring boot 2013 onwards popular in the world, until February 2017 to heat 100.
FIG. (2) google search interest in spring cloud
From the graph (2), we can see the spring cloud, starting in 2012 are relatively mild heat, after June 2015, that is, when the micro-services began to rise, spring cloud began to grow rapidly, in February 2017 Search heat reached 100. (China is not on the map, presumably because China is a wall out of reasons)
FIG. (3) spring boot Baidu search searches heat
Figure (3) is the result of Baidu map statistics, we can see that spring boot in the country was in June 2015 became popular in 2017, growth is particularly prominent.
FIG. (4) search spring cloud Baidu search interest
Figure (4) we can see, spring cloud from the June 2016 became popular in China, often new technology to be popular in China, will be a year behind Silicon Valley, Silicon Valley look a year ago, it is now China, so we will be able to determine the spring cloud in China's development curve, that is, in February 2018 spring cloud in China's heat will reach the top.
Although popular does not mean you need. However, since there is popular reason for his popularity, he had the advantage. Later we will come back next micro recognize service.
What is micro-services
Micro Services is a set of ways to build a small service applications, services run independently in different processes, interact through a lightweight communication mechanism (such as RESTful interface) between services, and services can be deployed independently by automated deployment . Because between the micro-service architecture, services are independent of each other, so that different services use different language to develop, or use different types of databases based on business needs.
The advantages and challenges of micro Services Architecture
Advantage
-
服务简单，只关注一个业务功能
传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。 -
每个微服务可由不同团队开发
传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。 -
微服务是松散耦合的
微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式。 -
可用不同的编程语言与工具开发
传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。
挑战
-
运维开销
更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。 -
DevOps要求
使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。 -
隐式接口
服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。 -
重复劳动
在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。 -
分布式系统的复杂性
微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。 -
事务、异步、测试面临挑战
跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。
微服务设计原则
-
隔离
服务必须设计为单独相互隔离工作。当你将一个整体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障，而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点：容易采用连续交付，更好的扩展，有效的监控和可测试性。 -
自治性
隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具有凝聚力，能够独立地实现其职能。每个服务可以使用良好定义的API（URI）独立调用。API以某种方式标识服务功能。自主服务还必须处理自己的数据。更流行的术语是多语言持久性，其中每个服务都有自己的持久存储。 自主还确保弹性。自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过良好定义的API进行通信，更快速和可控的部署。 -
单一责任
服务必须设计为高度凝聚。单一的职责（责任）原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。‘微’意味着小，细粒度，只与其责任范围内相关。单一责任功能具有以下优点：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。 -
有界上下文
您的服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。这也意味着跨边界的通信变得更有效率，在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。 -
异步通信
在设计离散边界和使用其自己的有界上下文设计服务时，跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合，并允许更好的缩放。使用同步通信，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务，直到接收到响应并释放底层线程为止。它导致网络拥塞，并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。 -
位置独立
根据设计，微服务是在虚拟化环境或docker容器中部署。随着云计算的出现，我们可以拥有大量可以利用动态缩放环境的服务实例。服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。必须能够以位置独立的方式来寻址或定位服务。通常，可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。