The simplified Chinese version is published by People's Posts and Telecommunications Publishing House. I read the simplified Chinese version.
-------------------------------------------------- -------------
The following is my own book review.
This book was published in 2016, and the English version was published in 2015. Microservices are relatively new. a technology (or idea) of . This book describes the theoretical ideas of microservices from a macro perspective. It can also be seen from the following directory structure. The author spends a chapter in Chapter 2 to talk about the role of architects in microservices. What are microservices? How do microservices find balance? How to test? And so on, these questions are answered by the author in the book.
The breadth of the book is very wide, introducing many tools, architectures and books, and the depth needs to be explored by yourself. Although it is an introduction to microservices, many ideas can also be applied to distributed architectures. All in all, it is a rare good book to expand knowledge~
------------------------------------ -------------------------------------
Introduction
Microservices are a distributed system solution that promotes The use of fine-grained services that work together, each with its own lifecycle. (It boils down to small, autonomous services).
The author's introduction to the structure of the book (table of contents) :
- Chapter 1, Microservices: First introduce the basic concepts of WeChat service, including the main advantages of microservices and some disadvantages.
- Chapter 2, The Evolutionary Architect: This chapter discusses the trade-offs that architects make and what specific aspects we need to consider in a microservices architecture.
- Chapter 3, How to Model Services: In this chapter we use Domain Driven Design to define the boundaries of microservices.
- Chapter 4, Integration: This chapter begins to dive into specific techniques, discussing what service integration techniques will help us the most. We'll also delve into the topic of user interfaces and how to integrate legacy products with COTS (Commercial Off-The-Shelf) products.
- Chapter 5, Decomposing Monolithic Systems: Many people are interested in how to decompose a large, hard-to-change monolithic system into microservices, and that's what we'll cover in detail in this chapter.
- Chapter 6, Deployment: Although this book deals primarily with the theory of microservices, there are several topics in the book that are influenced by the latest technologies, deployment is one of them, and we'll explore that in this chapter content.
- Chapter 7, Testing: This chapter digs into the topic of testing, which is important when deploying multiple distributed services. Of particular note is what role consumer-driven contract testing can play in ensuring software quality.
- Chapter 8, Monitoring: Testing before deploying to production doesn't fully guarantee that we'll be free from problems once we go live. This chapter explores how fine-grained systems can be monitored and how to deal with the complexity of distributed systems.
- Chapter 9, Security: This chapter will examine microservice security, considering how to handle user authentication and authorization to and between services. Security is a very important topic in computing, and it's easy to ignore. Although I'm not a security expert, I hope this chapter has at least helped you understand some of the things you need to consider when building a system, which is a microservice system.
- Chapter 10, Conway's Law and System Design: This chapter focuses on the interplay of organizational structure and system design. Many organizations have realized that a mismatch between the two can cause a lot of problems. We'll try to get to the bottom of this dilemma and consider a few different ways to match the system design to your team structure.
- Chapter 11, Microservices at Scale: In this chapter we will begin to understand the problems faced by microservices at scale in order to deal with the increased probability of failure and traffic overload when there are a large number of services.
- Chapter 12, Summary: The final chapter attempts to analyze how microservices are fundamentally different from other architectures. I have listed seven principles of microservices and summed up the main points of this book.
-------------------------------------------------- -----------------------
The following is an excerpt:
[Chapter 1]
Microservices Characteristics of microservices: cohesion and autonomy.
For a service, we need to consider what should be exposed and what should be hidden. There is a golden rule: can you modify one service and deploy it without affecting any other services? In order to achieve decoupling, you need to properly model the service and API.
For deployments, the greater the difference between releases, the greater the chance of errors. (Things that are deeply experienced in development~)
[Chapter 2] Evolutionary
Architect An important responsibility of the architect is to ensure that the team has a common technical vision to help us deliver the systems they want to our customers.
More precisely, architects can be like urban planners , not architects.
As an architect, you shouldn't focus too much on what's going on within each area, but more on what's going on between areas.
Rules are instructions to the wise and obedience to the foolish.
If you're in an organization with too many restrictions on developers, then microservices may not be for you.
I firmly believe that great software comes from great people. So if you're only worried about technical issues, I'm afraid you're seeing far less than half of the problems.
[Chapter 3] How to model a service
What kind of service is a good service: loose coupling and high cohesion.
When you're thinking about bounded contexts within your organization, you shouldn't think in terms of shared data, but in terms of the capabilities those contexts can provide. So first ask yourself "what is this context for" and then think about "what data does it need".
[Chapter 4] Integrated
REST is an alternative to RPC. (RPC: Remote Procedure Call, REST: Representational State Transfer.)
Developers are familiar with the acronym DRY, Don't Repeat Yourself. It follows Postel's Law (also known as the Robustness Principle, https://tools.ietf.org/html/rfc761 )
that clients consume service responses as flexibly as possible . The law holds that every module in the system should be "wide in and out", that is, be strict with what it sends and be lenient with what it receives. The original context of this principle is the interaction between network devices, because in this scenario, all kinds of strange things can happen. In the request/response scenario, this principle can help us reduce the modification of the consumer when the service changes. [Chapter 6] Deployment Continuous Integration (CI): 1) Do you check in code to mainline every day? 2) Do you have a set of tests to verify the modification? 3) When a build fails, does the team make fixing CI a first priority? Microservice integration recommendation: Each microservice has its own CI. Continuous delivery (CD) uses the standard release process of build pipeline modeling: linear translation and rapid testing --> time-consuming testing --> user acceptance testing --> performance testing --> production environment UAT: User Acceptance Testing, user acceptance test. Application container recommended pattern: one service per host. Platform as a Service ( PaaS )
: Platform-as-a-service): Heroku: Can manage the running of the service and also provide services such as databases in a very simple way.
Below: Comparison of standard type 2 virtualization and lightweight container technologies:
Type 2 virtualization: AWS, VMWare (I believe many people have used this), VSphere, etc.
Linux Containers: Thought/Or Example: If a process is started in the terminal, you can think of it as a child process of the terminal program. The task of the Linux kernel is to maintain this process tree. Each container is a subtree of the entire system process tree.
Docker is a platform built on top of lightweight containers.
Future trends: Containers as a Service: Caas (Communications-as-a-Service).
[Chapter 7] Testing
Test Classification System:
Process: Construction --> Unit Testing --> Service Testing --> [End-to-End Testing]
Canary Release: Refers to diverting some production traffic to new The deployed system to verify that the system performs as expected.
Mean time between failures and mean time to repair.
[Chapter 8] Monitoring
Monitor small services and then aggregate them to see the whole.
If we want to run our own monitoring software, we can use Nagios , or use a hosting service like New Relic to help us monitor our hosts.
One service, multiple hosts: Use the ssh -multiplexers tool to resolve.
Multiple services, multiple hosts:
- logstash ( http://logstash.net ), which can parse multiple log file formats and send them to downstream systems for further investigation.
- Kibana ( http://www.elastic.co/products/kibana ) is a system for viewing logs based on ElasticSearch.
Graphite: Provides a simple API that allows sending metrics data to it in real-time and then generating graphs of metrics (such as average CPU load).
Correlation IDs are recommended to track calls across multiple services.
[Chapter 9] Security
Generally speaking, when we discuss the person or thing that authenticates in the abstract, we call it a principal .
Single sign-on (authentication between people and services): Authentication
between services: HTTP(S) basic authentication (SSL certificate), using SAML or OpenId Connect, client certificates, HMAC over HTTP, API keys.
Encryption:
For encryption of data at rest, unless you have a good reason to choose something else, choose a well-known implementation of AES-128 or AES-256 on your development platform. (Regardless of the language, these encryption algorithms are peer-reviewed and regularly patched.)
For passwords, consider using something called salted password hashing ( https://crackstation.net/hashing ) -security.htm#properhashing )
key:
The encryption process relies on a data encryption algorithm and a key, and then uses both to encrypt the data. Regarding the storage of keys, one solution is to use separate security designs for encrypting and decrypting data.
Operating System: If you are using the Linux operating system, take a look at the development of the security module of the operating system itself. For example, AppArmour allows you to customize the expected behavior of your application, which is monitored by the kernel. If it starts doing something it shouldn't, the kernel steps in. (Ubuntu\SuSE uses AppArmour by default, while RedHat supports SELinux).
Example of a more secure system:
The golden rule of this chapter: Don't implement your own encryption algorithm, don't invent your own security protocol. Unless you are a cryptographic expert with years of experience.
[Chapter 10] Conway's Law and System Design
Our industry is still young, and some key laws have stood the test of time. Such as Moore's Law (it means that the number of transistors that can be accommodated on an integrated circuit doubles every two years.) There is another law, Conway's Law.
In a paper titled "How Do Committees Invent" published in April 1968 in the journal Datamation, Mel Conway pointed out that when any organization designs a system (a system in a broad sense), the The design proposals are all structurally aligned with the organization's communication structure .
A more detailed explanation: Eric S. Raymond summed up this phenomenon in The New Hackers Dictionary: If you have four groups developing a compiler, you get a four-step compiler.
For loosely coupled organizations (such as distributed open source communities) and tightly coupled organizations (such as commercial product companies), research shows that by matching different types of organizations with similar products, the lower the coupling degree of the issuing organization, the more the system it creates The better the modularity of the organization, the lower the coupling; the more coupled the organization, the less modular the system it creates.
[Chapter 11] Scale Microservices At
scale , even if you buy the best tools, the most expensive hardware, you cannot avoid the fact that they will fail.
In a distributed architecture, it is very important to be prepared for various failures, as follows:
timeouts, circuit breakers, bulkheads, isolation, idempotency,
scaling Load balance:
In addition, software like mod_proxy, Can play a role similar to a software load balancer.
Extended write operations: use sharding. Such as Mongo.
Cassandra handles this well for adding additional shards without downtime.
Caching: It is a commonly used method for performance optimization.
HTTP caching: cache-control directives, Expires headers, Etags, etc.
Server caching
CAP theorem : There are three aspects that need to be weighed against each other in a distributed system: consistency, availability, and partition tolerance. Specifically, the theorem tells us that at most two of the three are guaranteed.
ZooKeeper ( http://zookeeper.apache.org ) was originally developed as part of the Hadoop project. It is used in a dizzying variety of use cases, including configuration management, data synchronization between services, leader election, message queues, and naming services.
Consul ( http://www.consul.io ) also supports configuration management and service discovery.
Swagger lets you describe your API, producing a very friendly web user interface that allows you to view documentation and interact with the API through a web browser.
Hypertext Application Language: HAL (Hypertext Application Language.)
[Chapter 12] Summary
Microservices (autonomous small services), list some principles:
- Model around business concepts
- automated documentation
- Hide internal implementation details
- everything is decentralized
- Standalone deployment
- Quarantine failed
- highly observable
-------------------------------------------------- -----------------------
Other books, theories, techniques mentioned in the book:
Eric Evans "Domain Driven Design": Helped us understand presentation in code The importance of the real world, and tell us how to build better.
Alistair Cockburn "The Hexagonal Architecture Theory": Save us from a layered architecture, so that business logic can be better represented.
http://alistair.cockburn.us/Hexagonal+architecture
Robert C. Martin Single Responsibility Principle: Bring things together that change for the same reason and separate things that change for different reasons.
SOA (Service-Oriented Architecture): Service-Oriented Architecture.
OSGI (Open Source Gateway Initiative): Open Service Gateway Initiative.
Graphite: Collect metric data.
Nagios: Check health status.
Two JVM-based open source microcontainers : Dropwizard ( http://dropwizard.io ) and Karyon ( https://github.com/Netiflix/karyon )
Implementing Domain-Driven Design by Vaughn Vernon: Helps understand how to practice Domain-Driven Design method mentioned in.
Richardson's Maturity Model: A Comparison of Different Styles of REST. ( http://martinfowler.com/articles/richardsonMaturityModel.html )
Load Balancer: mod_proxy is
about REST over HTTP, and the book "REST in Action" gives a very detailed introduction to REST.
RabbitMQ: Message Brokers
"Enterprise Integration Patterns": Discusses many different programming patterns in detail.
Michael Feathers "The Art of Modifying Code"
Netflix has implemented a pipeline that can process large amounts of data and open sourced it. It is the Aegisthus project ( htts://github.com/Netflix/aegisthus ).
Docker related tools:
1) Google's recent open source tools Kubernetes and CoreOS cluster technology.
2) Deis: Provides Paas similar to Heroku on Docker.
Descriptive file format: YAML
Jez Humble and David Farly Continuous Delivery: This book has a more in-depth discussion of pipeline design and construct management.
Books on Testing: Brian Marick "Agile Software Testing", Mike Cohn "Scrum Agile Software Development", Freeman & Press's "Test-Driven Object-Oriented Software Development"
Test Doubles - TestDouble: https://www.martinfowler.com/bliki/TestDouble.html
Python web framework: Django
security expert Bruce Schneier expresses concern about certain types of key implementations in AES-256, related article: https://www. schneier.com/blog/archives/2009/07/another_new_aes.html
A browser-based application security site: the nonprofit OWASP (Open Web Application Security Project, http://www. owasp.org ), its regularly updated Top 10 Security Risks document, should be considered must-read for all developers.
More reading on cryptography: Cryptography Engineering by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno.
Book on caching: "REST in Action"
Chapter 13 of the HTTP 1.1 specification describes how clients and servers should implement different cache controls: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13 .html#sec13.3.3
Recommended Book: Nygard "Release it!": In this book the author shares a series of stories about system failures, and some patterns for dealing with them.