[-01] architecture reprint: micro Services Architecture
No public pure smile article: [12] I follow hand drawing micro Services Architecture!
What is micro-services?
Micro Services Architecture is an architectural pattern or a kind of architectural style, it advocates a single application into a set of smaller services, each running its own separate process, co-ordination between services, co-ordination, as to provide users with the ultimate value.
The use of lightweight communication mechanism between the service to communicate with each other (usually HTTP-based RESTful API). Each service around the specific business to build, and can be independently deployed into a production environment, production-like environment and so on.
In addition, you should try to avoid a unified, centralized service management mechanism, for a specific service should be based on the business context, select the appropriate language, tools to build them, can have a very lightweight centralized management to coordinate these services. You can use different language to write the service, you can use different data storage.
According to Martin Fowler's description, I summarized the following points:
① small service
Small service, no specific standards or norms, but he was on the whole specification must be small.
② independent process
Each set of services are run independently, may I run this service in Tomcat container, while another service running on Jetty. Way through the process, we continue to scale the entire service.
③ communication
Past agreements are heavy, like ESB, like SOAP, light communication, which means lighter than in the past smarter services call each other, it is the so-called smart endpoints and dumb pipes.
These are decoupled Endpoint, a complete business communications call these Micro Service strung like a Linux system through a series of commands strung pipeline business.
Past business, we usually consider a variety of dependency, consider coupling system brings. Micro service that allows developers to focus more on business logic development.
④ deployment
More than business to be independent, should be deployed independently. But this also means that the traditional development process will be a certain degree of change, developed for operation and maintenance should have a certain responsibility.
⑤ Management
Traditional enterprise SOA services tend to be large and difficult to manage, coupling high, team development costs is relatively large.
Micro service that allows each team to think their government's choice of technology to achieve different Service may choose a different technology stacks according to their needs to achieve its business logic.
Advantages and Disadvantages of Micro services
Why micro services? For fun? no. Here is what I find to say more full from the network advantages:
-
The advantage is cohesive enough to each service, is small enough, the code can be focused readily understood that such a specific business function or service requirements.
-
Development of simple, improve development efficiency, is a single-minded service may only do one thing.
-
Micro-service small team can be developed separately, this small team is 2-5 people development staff.
-
Micro services are loosely coupled, there is a functional significance of service, whether it is in the development stage or deployment phase is independent.
-
Micro service can use a different language development.
-
Ease and third-party integration, micro service allows easy and flexible way to integrate automatic deployment, through continuous integration tools, such as Jenkins, Hudson, bamboo.
-
Micro service easily understood by a developer, modify and maintain, such a small team can be more concerned about the outcome of their work. Without the need to reflect the value of cooperation. Micro service allows you to take advantage of integration of the latest technology.
-
Micro service is just the business logic code, and not HTML, CSS, or other interface components mixed.
-
Each service has its own micro-storage capacity, can have its own database, you can have a unified database.
In general, the advantages of micro-services, is that the face of large systems, can effectively reduce the complexity of the service logic architecture of clarity.
But it will also bring a lot of problems, such as data on consistency in distributed environment, the complexity of the test, the complexity of operation and maintenance.
Micro service with all sorts of advantages, drawbacks, then what is the use of micro-organization for service?
① Murphy's Law (system design) and Conway's Law (system partitioning)
Conway's Law, is a Over fifty years ago was put forward the concept of micro-services. In this article Conway, the most famous words:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Chinese interpreter probably means: system design organization, its design produced equivalent within the organization, communication structure between the organizations.
Look at the picture below, and then think about Apple's product, Microsoft's product design, vivid can understand this sentence.
② architecture evolution
Architecture is evolving out of the micro-service, too, when from major technology companies, large-scale to a certain extent, completely evolved technology architecture system needs further management.
The traditional team, are process-oriented technology, products, want to go over the planning, development planning finished looking, then follow the step by step to find.
Our technology is to make the product, once the process out what the problem is, looking back issues can be very time consuming.
Use a micro-services architecture system, team organization needs into cross-functional teams that each team has product experts, planning experts, development specialists, operation and maintenance experts, the way they use the API to publish their functions, and to use their platform feature release product.
Micro architecture technology service system
Let me share with you micro technology service system architecture used by most companies:
Service Discovery
Mainstream service discovery, divided into three types:
First, developers of the program in the future, will find operation and maintenance with a domain name, DNS services through the words we can find the corresponding service.
The disadvantage is that, because the service is not load balancing, load balancing services, there may be a significant performance issues.
Second, it is the common practice. Zuul gateway can refer to each service through the server the built-in functions registered to the registry, services, consumers continue to poll found corresponding service registry, use the built-in load balancing call service.
The disadvantage is, multi-language environment is not good, you need to separate the consumer client service discovery and development of load balancing. Of course, this method is usually used in the Spring Cloud.
The third is the client and load balancing on the same host, rather than within the same process.
This method is relatively first second method, the improvement of their shortcomings, but will greatly increase the cost of operation and maintenance.
Gateway
What micro gateway service is? We can contact real life to think about. Every large company will have their own one-sided construction area, which is built-up areas, there are a lot of guards. If there are foreign workers into the company, and the guard will first lay the greeting, to get in.
The real life linked to the micro-service, not difficult to understand the meaning of the gateway:
No public pure smile article: [12] I follow hand drawing micro Services Architecture!
What is micro-services?
微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
根据马丁.福勒的描述，我总结了以下几点：
①小服务
小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。
②进程独立
每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整个服务。
③通信
过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。
这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro Service 就像是 Linux 系统中通过管道串起一系列命令业务。
过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来的问题。微服务，可以让开发者更专注于业务的逻辑开发。
④部署
不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会出现一定程度的改变，开发的适合也要有一定的运维职责。
⑤管理
传统的企业级 SOA 服务往往很大，不易于管理，耦合性高，团队开发成本比较大。
微服务，可以让团队各思其政的选择技术实现，不同的 Service 可以根据各自的需要选择不同的技术栈来实现其业务逻辑。
微服务的利与弊
为什么用微服务呢？因为好玩？不是的。下面是我从网络上找到说的比较全的优点：
-
优点是每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
-
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
-
微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。
-
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
-
微服务能使用不同的语言开发。
-
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins，Hudson，bamboo。
-
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。
-
微服务只是业务逻辑的代码，不会和 HTML，CSS 或其他界面组件混合。
-
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。
但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。
微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？
①墨菲定律（设计系统）和康威定律（系统划分）
康威定律，是一个五十多年前就被提出来的微服务概念。在康威的这篇文章中，最有名的一句话就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
看看下面的图片，再想想 Apple 的产品、微软的产品设计，就能形象生动的理解这句话。
②架构演化
架构是不断演化出来的，微服务也是这样，当从各大科技公司，规模大到一定程度，完全需要演化成更进一步管理的技术架构体系。
传统的团队，都是面向过程化的，产品想完了去找策划，策划完了找开发，接着顺着一步一步找。
我们做技术都是为了产品的，一旦过程出来了什么问题，回溯寻找问题会非常耗时。
使用了微服务架构体系，团队组织方式需要转变成跨职能团队，即每个团队都有产品专家，策划专家，开发专家，运维专家，他们使用 API 方式发布他们的功能，而平台使用他们的功能发布产品。
微服务技术架构体系
下面我分享一下大部分公司都使用的微服务技术架构体系：
服务发现
主流的服务发现，分为三种：
第一种，开发人员开发了程序以后，会找运维配一个域名，服务的话通过 DNS 就能找到我们对应的服务。
缺点是，由于服务没有负载均衡功能，对负载均衡服务，可能会有相当大的性能问题。
第二种，是目前普遍的做法。可以参考 Zuul 网关，每一个服务都通过服务端内置的功能注册到注册中心，服务消费者不断轮询注册中心发现对应的服务，使用内置负载均衡调用服务。
缺点是，对多语言环境不是很好，你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然了，这个方法通常都是用在 Spring Cloud 上的。
第三种，是将客户端和负载均衡放在同一个主机，而不是同一个进程内。
这种方法相对第一种第二种方法来说，改善了他们的缺点，但是会极大增加运维成本。
网关
微服务的网关是什么？我们可以联系生活实际想一下。每一个大的公司，都会有一偏属于自己的建筑区，而这建筑区内，都有不少的门卫。如果有外来人员进入公司，会先和门卫打好招呼，才能进去。
将生活实际联系到微服务上，就不难理解网关的意思了：