翻譯一張大神的圖片
圖片地址：
https://github.com/dwmkerr/blog/blob/master/articles/2018/microservice-madness/images/questions.png
圖片內容：
圖片翻譯：
[1.Team Size]
can you fit your team around a large table?
yes: You might not need microservices yet(challenges around deployment, development, operations etc can probably be most easily handled by good communication and good design - microservices may be a solution to a problem you are not really suffering from.)
no: Microservices might help you(if your team is large, or you have many teams, you might not be able to enforce strong boundaries between components with good design alone. enforcing boundaries by separating components into isolated services may help.)
[1.團隊規模]
你能讓你的團隊圍成一張大桌子嗎?
是的:您可能還不需要微服務(圍繞部署、開發、操作等方面的挑戰可能最容易通過良好的溝通和良好的設計來處理——微服務可能是您並不真正遇到的問題的解決方案)。
不:微服務可能會幫助您(如果您的團隊很大，或者您有很多團隊，那么您可能無法僅通過良好的設計來強制組件之間的強邊界。通過將組件分離為獨立的服務來加強邊界可能會有所幫助。)
[2.State]
are you dealing with a primarily stateless system?
yes: consider serverless(If you are mostly stateless, you may be able to skip microservices and go straight to serverless, at least for parts of your system.)
no: microservices will come with complexity(This doesn't mean don't use microservices, but be aware that they will not be trivial to implement of manage, particularly as the system changes over time.)
[2.狀態]
您正在處理的主要是無狀態系統嗎?
是的:考慮使用無服務器(如果您基本上是無狀態的，那么您可以跳過微服務，直接使用無服務器，至少對於系統的某些部分是這樣)。
不:微服務將帶來復雜性(這並不意味着不使用微服務，但要注意，它們的實現和管理並不簡單，特別是隨着時間的推移，系統會發生變化)。
[3.Consumers]
are you building a solution for a single app or service?
yes: be careful - might have fuzzy domains(if everything you are building is for a single comsumer, you may find that when you build features, you might be updating many services at once. Microservices might be valid, but be extremely carefull in how you design you domains)
no: microservices may be very valuable(if you are designing for many diverse consumers, microservices may be a very sensible pattern to look into, to allow you to bring new features to new consumers quickly)
[3.消費者]
您正在為單個應用程序或服務構建解決方案嗎?
是的:小心-可能有模糊的域(如果您正在構建的所有東西都是針對單個消費者的，那么您可能會發現，當您構建特性時，您可能同時更新許多服務。微服務可能是有效的，但在如何設計域時要特別小心)
不:微服務可能非常有價值(如果您為許多不同的消費者進行設計，那么微服務可能是一種非常明智的模式，可以讓您快速為新消費者帶來新功能)
[4.Dependencies]
do you have monolithic dependencies?
yes: performance might be an issue(independently scalable services are unlikely to be a benefit in this case, as you are dependent on the performance of your dependencies. so some of the key benefits may be unacheivable. you might also have less well defined boundaries to your services.)
no: microservices may be very valuable(if you are not constrained by monoliths downstream, you might be able to achieve th high degree of independence required for effective scaling of microservices)
[4.依賴關系]
您有獨立的依賴關系嗎?
是的:性能可能是個問題(在這種情況下，獨立的可伸縮服務不太可能帶來好處，因為依賴於依賴項的性能。因此，一些關鍵的好處可能是無法實現的。您的服務可能也沒有很好的定義邊界。)
不:微服務可能非常有價值(如果您不受下游巨石的限制，您可能能夠實現有效擴展微服務所需的高度獨立性)
[5.Expertise]
got container / orchestration / devops experts?
yes: microservices may be very valuable(if you've got the chops, it might be worth looking into microservices, you have the skills to deal with the complexities which will arise and can probably capatalise on the benefits)
no: consider testing the water first(if you don't have the expertise, or are already struggling with devops, this might be to much of a jump. perhaps consider a small simple service as a spike or proof of concept. learn the skills on projects which are not mission-critical first)
[5.專業知識]
有容器/編制/ devops專家嗎?
是的:微服務可能非常有價值(如果你有能力，那就值得研究一下微服務，你有能力處理將會出現的復雜問題，並且很有可能從中獲益)
不可以:考慮先測試水(如果您沒有相關的專業知識，或者已經在與devops做斗爭，那么這可能是一個很大的飛躍。也許可以將一個簡單的小服務看作是概念的一個尖峰或證明。(首先要學習任務無關緊要的項目的技能)