Microservice笔记

Resources

Martin Fowler Articles : 

• https://martinfowler.com/articles/microservices.html
• https://martinfowler.com/videos.html#microservices
• https://martinfowler.com/bliki/MicroservicePrerequisites.html
• https://martinfowler.com/articles/microservice-testing/
• https://martinfowler.com/bliki/MicroservicePremium.html
• https://martinfowler.com/articles/microservice-trade-offs.html#summary
• https://martinfowler.com/articles/distributed-objects-microservices.html

Digest

Background

• The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
• "Write programs that do one thing and do it well. Write programs to work together" was accepted 40 years ago yet we have spent the last decade building monolithic applications, communicating via bloated middleware and with our fingers crossed that Moore's Law keeps helping us out. There is a better way.
• Micro services : a consistent and reinforcing set of tools and practices rooted in the the Unix Philosophy of small and simple. Tiny applications, communicating via the web's uniform interface with single responsibilities and installed as well behaved operating system services.

Problem To Solve :

• Productivity = Fn(Complexity); Productivty decreases as oppose to Complexity grows;

Challenge :

Monolith Complexity (When Getting Too Big)

• scaling
• allowing different business functions to evolve independently
• supporting many user interaction models
• multi-tenancy
• large teams
• too big to deploy (for a minor single piece of change)
• too big to modify (knowledge of whole system)

Approach

• less coupling (MONOLITH to MICROSERVICE) to decrease Complexity

Solution : MICROSERVICE

• Component (Encapslusion, public v.s. private)
  • Service Boundaries
  • Independently upgradable, replacable and deployable
• Yet, with with other complexities 
  • Team Skill 
  • Deployment
  • Monitoring
  • Inter Process Communication (Cost, Protocol, etc)
  • Failure Handling
  • Eventual Consistency
  • ......

Solution : MICROSERVICE Pros

• Strong Module Boundaries
• Independent Deployment
• Technology Diversity
• Scalablity (Only Invest In What Is Needed)
• Security Enhancement (hopefully by encapsulation

Solution : MICROSERVICE Cons (Premium)

• Distribution (Complexity) - in process call v.s. inter-process call
  • protocols : rpc, ws, etc;
  • synchronized call
    • still tight coupling (downtime : service end)
    • performance drawback - network, searlization, etc;
      • batch operation
      • a-synchronized
  • contract (interface, api)
    • failure tolerant 
    • upgradability
      • extension point
      • versioning as last resort (url v.s. header)
• Eventual Consistency (Complexity)
• Operational Complexity
• Testing Complexity

Feasibility

Pros - Cons = Productivity Increase?

• Doghouse v.s. Skyscraper
• Lines of Code (Rough & Based on language)
  • 1 - 50 : single file;
  • 50 - 500 : few files, few functions;
  • 500 - 1,000 : library, class hierarchy;
  • 1,000 - 2,000 : framework, application;
  • 2,000+ : multi-applications;

Supplementary : Service Integration

• Considerations

Corss System	System Internal
Responsibilities Communication protocols UI integration BI interfaces Data formats Redundant data Logging, Monitoring	Programming languages Development tools Frameworks Persistence Process/Workflow control Design patterns Coding guidelines

• Objective Over Time

Ease of development
Homogeneity
Cohesion
Simplicity	Modularity
	Decoupling
	Heterogeneity
	Autonomy

• Separate System Integration
  • Frontend Integration
  • Backend Integration
  • Data Sharing (the worst)
• Why Data Redudency Good?
  • In-process Call Stack : high success probability
  • Distributed (cross-system) Call Stack : low success probability
  • Data Redudency (as a way to reduce inter-system calls)
• Frontend Integration 
  • Approach 1 - Centralized Front End Server (Not Suggested)
    • Aggregate backend result and rendering different UIs
      • ESI-Caches
      • SSI
      • Portal Server
  • Approach 2 - Client Side Integration
    • Client call backend server directly
      • Ajax
  • Approach3 - Links

转载于:https://my.oschina.net/u/3551123/blog/979112